Closed Bug 45953 Opened 24 years ago Closed 22 years ago

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

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: jrgmorrison, Assigned: dougt)

References

()

Details

(Whiteboard: [nsbeta2-])

Attachments

(1 file)

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).
Keywords: netcenter, nsbeta2
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]
Nisheeth, can you look into this and get PDT some info?
Keywords: 4xp
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. 
Keywords: nsbeta3
Whiteboard: [NEED INFO] → [nsbeta2-]
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 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Netcenter uses URLs with embedded LF-TAB; mozilla can't load them → URL: embedded LF-TAB; mozilla can't load them
-> defaults
Assignee: gagan → dougt
Status: REOPENED → NEW
QA Contact: tever → benc
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
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
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.
Assignee: adamlock → dougt
Component: Embedding: Docshell → Networking
QA Contact: adamlock → benc
Is the testcase still valid? I think this works now.
wfm too.
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WORKSFORME
V/wfm:
the controversy about URL bar lives on, to this day, in bug 23485.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: