Closed
Bug 8319
Opened 25 years ago
Closed 25 years ago
{compat} Spaces in 'href' atttribute lost in content sink
Categories
(Core :: DOM: HTML Parser, defect, P4)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: dennis.m.ginley, Assigned: buster)
Details
(Whiteboard: 7/13 Looking for info on whether the page should or should't load if there's a space in the link...)
Summary: Clicking a link to a page whose filename contains a space won't display
the page.
Steps to reproduce:
0) Launch Viewer
1) Load a page that contains a link to another page whose filename contains a
space. e.g. <A href="Text Color.html">Text Colors</A>
2) Click the link
Result:
* The page does not load, but Viewer claims that it has loaded. The status bar
at the bottom of the window has the message: "<path>/TextColor.html done" Note
that the space between 'Text' and 'Color' has been removed.
* At this point, doing File/View Source opens a window for TextColor.html, so
the Viewer appears to believe that it has loaded the page.
* The terminal window from which the Viewer was launched displays the message:
nsDocumentBindInfo::OnStopBinding: Load of URL '<path>/TextColor.html' failed.
Error code: 1
However, just to make it a little more complicated, 'File/Open/Text Color.html'
works perfectly. The file list displays all the filenames with spaces correctly,
and, after the file loads its name is displayed with the space replaced by %20,
which is what Netscape and IE both do.
The parsing engine is passing the correct link "xxx yyy" to the content sink.
Somewhere in there, it appears to be losing the spaces. Reassign to kipps plate
till I can look at it later. Low priority issue, BTW.
Updated•25 years ago
|
Severity: normal → minor
Priority: P3 → P4
Summary: Clicking a link to a page whose filename contains a space won't display the page. → {compat} Spaces in 'href' atttribute lost in content sink
Target Milestone: M10 → M15
Comment 2•25 years ago
|
||
Note that an href containing a space is invalid. The 'href' attribute should
be URL-encoded, which means that the example you give should really read:
<A href="Text%20Color.html">Text Colors</A>
Marking this bug {compat}, accepting as M15 (which just means that Kipp will
look at it when he comes back, not that it won't get fixed until M15), lowering
priority and severity, updating summary.
Note: the problem is definitely occuring during the document load (as Rick
says above) -- not during the link processing (after the click).
Comment 3•25 years ago
|
||
Be aware also of bug #7399 which also concerns spaces in href (although
it is not the same bug as this).
While I agree that 'URL' should never contain literal space characters
(and the RFC is clear on this point), bug #7399 has some links to a
working draft and some discussions on xml-dev that argue that this may
be (???) the 'new' way. (I hope not).
Comment 4•25 years ago
|
||
The way I interpret those specs, they just say that we should be escaping
illegal characters, not that illegal characters are to be allowed in documents.
Comment 5•25 years ago
|
||
Yes. I agree. For the i18n reason. My concern is simply with the 'space'
character (%20) -- if Mozilla supports this auto-escaping (IE does already),
then 'spaces' in URL/URI will become quite commonplace -- a de facto standard
contrary to RFC 2396. (Not a good thing, in my (inconsequential) opinion).
It turns out that the content classes (my bad) were stripping off whitespace out
of strings that are url's.
The content should just store what its given, and leave it up to the networking
library to validate urls...
Fixed...
Updated•25 years ago
|
Whiteboard: 7/13 Looking for info on whether the page should or should't load if there's a space in the link...
Comment 8•25 years ago
|
||
And this one is fixed, too. I'm going to re-resolve as FIXED.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Comment 10•23 years ago
|
||
Verified on
build: 2001-05-29-20-Trunk
platform: Win NT
The test case that contains a link to another page whose filename contains a
space loads fine.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•