Subject: url bug

From: Nancy McGough <[email-masked]>
Date: Sat, 16 Feb 2002 15:45:26 +0000 (GMT)

Pine's gotten pretty good at figuring out where exactly a URL or
web address begins and ends and making it a link. I just noticed
this in Jeremy Howard's sig

  http://FastMail.FM:

and Pine includes the trailing colon in the link. I think that
Pine is pretty good at excluding punctuation that's at the end of
a URL, e.g., I think this will work in Pine

  http://FastMail.FM.

We'll see after this arrives in Pine. So this brings up 2
requests

* Please exclude characters that URLs don't end with in the
algorithm for selecting URLs. Maybe it is legal for a URL to end
in a colon and that's why Pine includes it???

* It would be great if there were an option to have Pico
highlight URLs and web addresses so I could tell if the second
URL would be turned into a link right now, rather than having to
wait until it shows up in Pine.

Thanks,
Nancy
^x

-- 
ii Main Pine Page: <http://www.ii.com/internet/messaging/pine/>

Nancy McGough           <http://www.ii.com/>           Infinite Ink
--= Sent via Pine 4.44: IMAP, NNTP & ESMTP for Unix/Win/MacOS X =--

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Jacob Morzinski <[email-masked]>
Date: Sat, 16 Feb 2002 13:31:19 -0500

>   http://FastMail.FM:

[...]

>   http://FastMail.FM.

[...]

> in a colon and that's why Pine includes it???

It is legal for a URL to end in a colon (or a period) -- see the entries 
for "hsegment" and "search" in rfc 1738.  Technically, it is not legal 
for the host+port part of a URL to end in a colon.  If a colon is 
present, the port number should be present.  Despite this technicality, 
all the browsers I tested were happy to accept a colon-but-no-port URL; 
they simply connected to the default port of the server.

I haven't tried Pine 4.4x yet.  If it or some later version wants to 
include a rigorously rfc compliant URL parser that leaves out the colon 
in your first example, good for it.  If a rigorous parser exists, 
though, it will certainly *include* the trailing "." in your second 
example, because trailing periods have a definite meaning in hostnames.

  -Jacob Morzinski

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 16 Feb 2002 20:55:14 +0100 (CET)

> in a colon and that's why Pine includes it???

If you put the URL's within "<>" you have a clear ending. I think that
there is an RFC recommending that, e.g. <http://www.sunet.se/>.

Mats

-----------------------------------------------------------------
Mats Dufberg                                 [email-masked]
Blåarvsgränd 42                                    +46-8-38 48 59
SE-162 45 Vällingby, Sweden                       +46-70-258 2588

---

From: Nancy McGough <[email-masked]>
Date: Sun, 17 Feb 2002 07:44:41 +0000 (GMT)

> there is an RFC recommending that, e.g. <http://www.sunet.se/>.

Yes, this is what I do, especially with long URLs or URLs that
are surrounded by punctuation. The problem is that I can't
control what other people do and it would be nice if Pine were as
smart as possible about rendering URLs that aren't surrounded by
angle brackets.

BTW, one of my Pine wishes is about Pine's interpretation of
mult-line URLs that are surrounded by angle brackets. My wish
list is here

 <http://www.ii.com/internet/messaging/pine/#wishesMisc>

Thanks,
Nancy
^x

---

From: Joel Boonstra <[email-masked]>
Date: Mon, 18 Feb 2002 10:21:27 -0500 (EST)

> there is an RFC recommending that, e.g. <http://www.sunet.se/>.

I have done that for awhile, but I got messages back from people asking
'What URL', or 'What email address'.  So I re-send the same message, and
they still dont' get anything.  I was confused, till I got a glance at the
actual message they were seeing.  Seems their mail reader stripped out the
stuff between the <>, assuming it was an HTML tag to be rendered.  Bet you
can't guess which one...

Anyway, I've tried to switch to putting my URLs and email addresses
between [], like [http://www.google.com/].  Pine doesn't care, and I think
it may prevent buggy mail clients from stripping out my message where I
didn't intend it to be stripped.

Just my experience,

-- 
[ joel boonstra | [email-masked] ]

---

From: Dan Hatton <[email-masked]>
Date: Mon, 18 Feb 2002 23:37:53 +0000 (GMT)

On Mon, 18 Feb 2002, Joel Boonstra wrote:

> between [], like [http://www.google.com/].  Pine doesn't care

Sadly, Pine 4.21 does care: it includes the closing ] as part of the URL,
leading to an error 404 from Google.

---

From: Joel Boonstra <[email-masked]>
Date: Mon, 18 Feb 2002 23:06:19 -0500 (EST)

> Sadly, Pine 4.21 does care: it includes the closing ] as part of the
> URL, leading to an error 404 from Google.

Ugh.  It's nice to see that 4.44 doesn't mind.

Oh well -- the people that I email most undoubtedly don't use pine, and if
they do, they'll also be able to figure out how to cut and paste ;)  I
still call this a better option than having confused Outloo...er, non-pine
users on my hand.

Joel

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 23 Feb 2002 23:29:39 +0100 (CET)

On Feb 18, 2002, 10:21 (-0500) Joel Boonstra <[email-masked]> wrote:

> I was confused, till I got a glance at the

In a text message (text/plain)? That was strange... So that means that you
can't write something like

while ( x < 10 ) { print "error" if x > 10;

Isn't there a patch to that bug?

Mats

---

From: Joel Boonstra <[email-masked]>
Date: Mon, 25 Feb 2002 01:26:42 -0500 (EST)

> > I was confused, till I got a glance at the actual message they were
> > seeing.  Seems their mail reader stripped out the stuff between the
> > <>, assuming it was an HTML tag to be rendered.  Bet you can't guess
> > which one...
>
> In a text message (text/plain)? That was strange... So that means that
> you can't write something like
>

It's not a pine bug, it's a bug in whatever email client (perhaps AOL,
perhaps Outlook, I don't recall) the person receiving my email was using.
I can't replicate it, as I thankfully don't have either of those clients,
but my guess is that your example would look like this:

   while ( x  10;

In general, I think it's safe to assume that the content-type has little
bearing on how some email clients choose to recognize and display email.
And patches?  How can patches be released if people can't get at the
source to see what's wrong?

Anyway, it was a lot easier to change my email composition practices than
to try to convince everyone in the world to switch to a better client.

Joel

---

From: Dan Hatton <[email-masked]>
Date: Mon, 25 Feb 2002 12:38:13 +0000 (GMT)

> perhaps Outlook, I don't recall) the person receiving my email was using.

The makers of Outlook seem to know about using angle brackets to mark
the start and end of URLs, where it isn't easy to detect the start and
end automatically:
<http://www.microsoft.com/office/ork/2000/five/70t3_2.htm>.  It also
appears that Microsoft have acknowledged, and issued a fix for, a
server bug which causes exactly this problem:
<http://support.microsoft.com/default.aspx?scid=kb;en-us;Q232384>.

Dan

================================================================================

			Daniel C. Hatton B.A., M.Sci., A.M.Inst.P.
			Graduate Student

E-Mail:			[email-masked]

World-Wide Web:		http://www.bib.hatton.btinternet.co.uk/dan/

Surface Mail:		Wolfson Court,
			Girton College,
			Clarkson Road,
			Cambridge,
			UK.
			CB3 0EH

================================================================================

---

From: Joel Boonstra <[email-masked]>
Date: Mon, 25 Feb 2002 16:42:57 -0500 (EST)

> appears that Microsoft have acknowledged, and issued a fix for, a server
> bug which causes exactly this problem:

That says it's for 'text/enriched' messages, but perhaps it also occurs
for other mime-types.  It's nice to see a fix for the problem.  Now the
big problem is getting users to understand what they need to ask their
sysadmin to do to fix the problem.

Thanks for that info, though -- it is helpful.

Joel