URL: embedded LF-TAB; mozilla can't load them




18 years ago
14 years ago


(Reporter: John Morrison, Assigned: dougt)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2-], URL)


(1 attachment)



18 years ago
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
                      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).


18 years ago
Keywords: netcenter, nsbeta2

Comment 1

18 years ago
Created attachment 11620 [details]
testcase; LF-TAB broken URL from Netcenter

Comment 2

18 years ago
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?
Whiteboard: [NEED INFO]

Comment 3

18 years ago
Nisheeth, can you look into this and get PDT some info?
Keywords: 4xp

Comment 4

18 years ago
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?). 

Comment 5

18 years ago
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.

Comment 6

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding "nsbeta3" keyword 
for consideration of a fix for that milestone. 
Keywords: nsbeta3
Whiteboard: [NEED INFO] → [nsbeta2-]

Comment 7

18 years ago
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 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 8

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

Comment 9

16 years ago
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.
Resolution: DUPLICATE → ---
Summary: Netcenter uses URLs with embedded LF-TAB; mozilla can't load them → URL: embedded LF-TAB; mozilla can't load them

Comment 10

16 years ago
-> defaults
Assignee: gagan → dougt
QA Contact: tever → benc

Comment 11

16 years ago
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.
Component: Networking → Embedding: Docshell

Comment 12

16 years ago
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.
Assignee: dougt → adamlock
QA Contact: benc → adamlock

Comment 13

16 years ago
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.

Comment 14

16 years ago
URI fixup doesn't happen for link clicks. I suspect this should either in the
URI parsing code.

Reassign to networking.
Assignee: adamlock → dougt
Component: Embedding: Docshell → Networking
QA Contact: adamlock → benc

Comment 15

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

Comment 16

16 years ago
wfm too.
Last Resolved: 18 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 17

14 years ago
the controversy about URL bar lives on, to this day, in bug 23485.
You need to log in before you can comment on or make changes to this bug.