Overview Description: Netcenter is generating pages that include URLs with a LF-TAB sequence in the middle. NOTE: These URL are "accepted" by Nav4.x and IE5.0 and interpreted as if the LF-TAB were not there. Steps to Reproduce: 1) Load the attachment (a verbatim extract from a Netcenter page). 2) Click on one of the links. This is the form of the URLs in the page: <A HREF="http://info.netscape.com/fwd/nw_headli/http://dailynews.netscape.com /news/Sports/07_19_2000.rostz1704-story-bcsportsalbluejaysdc.html">Media Company Looking to Buy Toronto Blue Jays</A> Actual Results: An alert comes up "info.netscape.com could not be found. Please check the name and try again." Expected Results: Hmm. Well it's not a valid URL (unless this is some obscure rule that I don't know). What the error handling (or backward compatibility) should be in this case is up to Necko (or perhaps XPApps). Reproducibility: 100% Build Date & Platform Bug Found: 2000071910 win2k 2000071910 linux 2000071912 macos Additional Information: It seems that both IE and Nav4 will elide LF and TAB (but not SPC) from the URL and use that URL as the target for the GET. Adding netcenter and nsbeta2 keywords -- we can't go to PR2 and not be able to view our own website. (My personal opinion is that this should be WONTFIX, and Netcenter should simply stop using this syntax -- I don't know of anywhere else on the web that expects a LF-TAB in a URL to not break loading of that URL).

Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix to make a call on this bug. How common is this syntax across the web? Is this worth pulling pr2 off the wire for?

Nisheeth, can you look into this and get PDT some info?

As I noted, this may be WONTFIX. Even if it was to be fixed, it would not likely be worth the risk to do this for beta2. However, what should be certainly be done for beta2 is to have Netcenter stop using this bogus syntax (it is bogus, right Andreas?).

Yes, they are definitly bogus. But currently we don't drop them (as N4.x or IE), we simply escape them as any other character that is not allowed in an url or we convert them into spaces (this depends on where the url is coming from). There is another bug that deals with this sort of problem, take a look at (still open M16 bug!) bug 23485.

Putting on [nsbeta2-] radar. Not critical to beta2. Adding "nsbeta3" keyword for consideration of a fix for that milestone.

To me this looks like a dup of bug 23485. The same should just apply for links off of the page. Reopen if thats not the case. If this does get reopened then someone in webshell should look at it. *** This bug has been marked as a duplicate of 23485 ***

Since bug 23485 is all about cut-and-paste issues, is it really going to handle this case -- clicking on a link?

REOPEN: What code decides what stuff inside the < > is a URL that is sent to Necko? This might be a dupe of some other bug I haven't found yet, but RFC 2396 says this is a valid URL. In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URI across lines. The whitespace should be ignored when extracting the URI. I know from another bug I recently looked at, that we decided to encode rather than swallow spaces in a single line of a URL, so careless references to filenames w/ a space would work, but the larger whitespace-across-lines seems like it should work.

-> defaults

over to docshell. andreas says LF-TAB's are escaped currently. if we want to drop them, the nsDefaultURIFixup probably will be doing this, iirc.

over to docshell. andreas says LF-TAB's are escaped currently. if we want to drop them, the nsDefaultURIFixup probably will be doing this, iirc.

That information is really old, as far as I know we now remove \r \n \t from the beginning and the middle of an url, but only remove spaces from the end. See FilterString in nsStandardUrl.cpp. But there still is the issue of removing spaces around a linebreak (as requested by rfc 2396) which may or may not be a good thing and can only be decided within docshell with a known context, not within necko.

URI fixup doesn't happen for link clicks. I suspect this should either in the URI parsing code. Reassign to networking.

Is the testcase still valid? I think this works now.

wfm too.

V/wfm: the controversy about URL bar lives on, to this day, in bug 23485.