444009 - URLs in message display are truncated at pipe symbol

Status: RESOLVED INVALID

(MailNews Core :: MIME, defect)

Description

[Kevin Murie]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: 

URL's within a received e-mail which contain a pipe symbol( | = Decimal 124) are truncated at the character preceeding the pipe symbol causing the URL to break.

Reproducible: Always

Steps to Reproduce:
1. Select an e-mail with a URL containing ASCII code 124 (pipe symbol.)
2. Cick on said link.
3. Link is truncated at character preceding said character and URL is launched.
Actual Results:  
Link is truncated (up to the character preceding the pipe symbol) and resultant link is launched in browser.

Expected Results:  
I would expect the entire link to be transferred and launched as is without modification by the email client.

Eudora should not truncate URLs ever.

It is still possible (of course) to copy the URL from the e-mail and paste into the address bar of the browser without the truncation issue.

Comment 1

[Matt Dudziak]

Do you have an example of such a link?

Comment 2

[Kevin Murie]

As per your email request for a specific URL:

http://safelister.com/Bingo.cgi?a=79593||1224135203||4

I've also noticed since I posted about this 'bug' ... If the e-mail is composed of straight 7 big ascii text, the URL is broken as I state in the original report.  If the e-mail uses html formatting, the URL is intact (sometimes.)  I am not 100% positive about this however.  But I do notice sometimes the URL is complete including the text after the pipe symbol, and sometimes it truncates at the pipe symbol.  I am not completely sure what determines what keeps the URL in it's entirety, or what causes the truncation.

Sorry I'm not of more help.

Any further questions or required clarification, please do not hesitate to e-mail.

Kevin

Comment 3

[Matt Dudziak]

Problem is also present in Thunderbird so changing product to Thunderbird so more eyes see this.

Comment 4

[:aceman]

I think there are some characters on which the underlining terminates automatically. Because some people write '.' or ':' straight after the URL and expect the underlining stop before that char. See e.g. bug 424064. However, that should happen when that special char is at the and of the URL (and space is the next char).
There are different rules for allowed characters inside URLs. I'll check that.

Comment 5

[:aceman]

I have found out that | (pipe) is intentionally defined to terminate an URL (in mozTXTToHTMLConv.cpp). Does anyone have a spec on this? Or is this just unfortunate side effect of protecting against other garbage texts, where | should not be a part of the URL?

Comment 6

[:aceman]

I was told dbienvenu and bzbarsky could help here.

Comment 7

[David :Bienvenu]

Ben can probably help.

Comment 8

[Ben Bucksch (:BenB)]

> I have found out that | (pipe) is intentionally defined to terminate an URL
> (in mozTXTToHTMLConv.cpp)

That is correct.

> Does anyone have a spec on this?

On the implementation: <http://www.bucksch.org/1/projects/mozilla/16507/>
The relevant Internet spec was RFC 2396.

RFC 2396 Section 2.4.3 <http://www.apps.ietf.org/rfc/rfc2396.html#sec-2.4.3>

Thus, this is not a bug, but intentional as aceman said.

Comment 9

[Ben Bucksch (:BenB)]

> RFC 2396 Section 2.4.3 <http://www.apps.ietf.org/rfc/rfc2396.html#sec-2.4.3>

..specifically excludes the pipe symbol. Therefore, it's not included in our URL guessing (!).