Bugzilla – Bug 12543
[URL] Replacing backslash with forward slash in URIs doesn't seem to be necessitated by web compat
Last modified: 2013-04-11 15:51:18 UTC
Replacing backslash with forward slash in URIs doesn't seem to be necessitated
by web compat
Posted from: 188.8.131.52
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110422 Firefox/6.0a1
In particular, Gecko does not do this, an while there were some reports about it back about 10 years ago; it's been years since we last had a report about it.
Given that, we don't think this particular IE quirk is something worth imposing on the web forevermore.
This surprises me. Does Gecko support \ in file URLs on Windows?
Gecko does support replacing backslash with forward slash in file: URLs on Windows and OS/2.
Gecko also supports, on Windows and OS/2, converting backslashes in urls typed in the url bar (but NOT urls in web pages) to forward slashes, if the scheme is one of "http", "https", or "ftp".
There are no other cases in which we do such replacement.
See the net_NormalizeFileURL call in nsFileProtocolHandler::NewURI for the former replacement and the XP_WIN|XP_OS2 block in nsDefaultURIFixup::CreateFixupURI for the latter fixup.
Moreover, the current spec asks User-Agents to replace backslashes AFTER resolving the URI. But actual implementations (at least Mozilla on Windows for file URIs) replace it BEFORE resolving. Otherwise relative path resolving will not be handled correctly (consider about ".\" or "..\" or "\topleveldirectory").
It's obvious that the backslash replacement clause was added in an unconsidered way.
Eventually this section will be replaced by http://tools.ietf.org/html/draft-abarth-url so it might be better to focus on that draft.
mass-move component to LC1
(In reply to comment #5)
> Eventually this section will be replaced by
> http://tools.ietf.org/html/draft-abarth-url so it might be better to focus on
> that draft.
Adam? Any plan to update the URL draft to address this?
> Adam? Any plan to update the URL draft to address this?
I'm not planning to update that draft anytime soon.
un-assigning Adam for this per comment #8
Does anyone know if we have a component for URL spec issues? Or any other tracking mechanism?
(In reply to comment #10 from Hixie)
> Does anyone know if we have a component for URL spec issues? Or any other
> tracking mechanism?
we do now
Moving back to component="LC1 HTML spec" in order to comply with the decision policy, and cloned this bug to create bug 15684
Hixie, I would suggest that you change the status on this bug to RESOLVED with a comment that the plan is for this to be handled in the URL spec, and that bug 15684 is the bug for tracking this going forward.
If you do that and anybody objects to this bug being resolved that way, the decision policy gives them the option of reopening this bug and explaining why.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
Change Description: no spec change
Rationale: see comment 12
*** Bug 14693 has been marked as a duplicate of this bug. ***
Please keep this bug open until the text it is about is indeed gone.
This needs to be resolved prior to entrance to CR. See also http://lists.w3.org/Archives/Public/public-html/2012Nov/0201.html
I'm moving this to .next because:
• It won't be addressed before CR;
• It's probably too big of a change to address in CR;
• While not specified in an optimal manner, the behaviour appears to be supported by all browsers save one and so is widespread (user questions on StackOverflow show that it does lead to interop issues);
• The slated replacement for this section (Anne's URL spec) maintains this feature.
So all in all, removing this text now would do more harm than good, and would be less in line with reality than including it, even if it is imperfect. This doesn't mean we're giving up on perfection: that's what .next is for.
Mass move to "HTML WG"
Reviving discussion for this on public-html:
Reassigning to Silvia, to cherry-pick from the WHATWG spec:
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:
Change Description: Adopted the WHATWG change to integrate with URL specification (which omits the logic errors of the original URL parsing algorithm outlined in HTML5)
This was originally a LC1 bug which was won't fixed (Comment 13) in order for discussion to continue in cloned WHATWG bug 15684, which was ultimately won't fixed. In the meantime, Bug 14693, which points out a logical error in the URL parsing algorithm, was duped to this bug. This bug was then reopened on the grounds that it should not be resolved until the erroneous text of the algorithm be removed and the logic ammended. The following commit merged from the WHATWG spec does this and defers to the URL specification to define parsing logic:
Going forward, bugs in URL parsing should be filed on that spec.
This is actually WONTFIX because WHATWG specs WONTFIXed the corresponding bug 15684.