Bug 12543 - [URL] Replacing backslash with forward slash in URIs doesn't seem to be necessitated by web compat
[URL] Replacing backslash with forward slash in URIs doesn't seem to be neces...
Status: RESOLVED WONTFIX
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
unspecified
Other other
: P3 normal
: ---
Assigned To: Silvia Pfeiffer
HTML WG Bugzilla archive list
http://www.whatwg.org/specs/web-apps/...
:
: 14693 (view as bug list)
Depends on:
Blocks: 15684
  Show dependency treegraph
 
Reported: 2011-04-23 01:28 UTC by contributor
Modified: 2013-04-11 15:51 UTC (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2011-04-23 01:28:20 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#resolving-urls

Comment:
Replacing backslash with forward slash in URIs doesn't seem to be necessitated
by web compat

Posted from: 71.184.125.56
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110422 Firefox/6.0a1
Comment 1 Boris Zbarsky 2011-04-23 01:29:52 UTC
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.
Comment 2 Adam Barth 2011-04-23 02:58:13 UTC
This surprises me.  Does Gecko support \ in file URLs on Windows?
Comment 3 Boris Zbarsky 2011-04-23 03:31:48 UTC
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.
Comment 4 Masatoshi Kimura 2011-04-23 04:00:38 UTC
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.
Comment 5 Anne 2011-06-22 21:48:04 UTC
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.
Comment 6 Michael[tm] Smith 2011-08-04 05:34:38 UTC
mass-move component to LC1
Comment 7 Michael[tm] Smith 2011-11-20 14:35:14 UTC
(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?
Comment 8 Adam Barth 2011-11-20 18:18:27 UTC
> Adam? Any plan to update the URL draft to address this?

I'm not planning to update that draft anytime soon.
Comment 9 Michael[tm] Smith 2011-11-20 21:00:46 UTC
un-assigning Adam for this per comment #8
Comment 10 Ian 'Hixie' Hickson 2011-12-02 17:57:05 UTC
Does anyone know if we have a component for URL spec issues? Or any other tracking mechanism?
Comment 11 Michael[tm] Smith 2011-12-03 05:07:40 UTC
(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
Comment 12 Michael[tm] Smith 2012-01-24 01:17:05 UTC
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.
Comment 13 Ian 'Hixie' Hickson 2012-01-25 23:44:06 UTC
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:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 12
Comment 14 Ian 'Hixie' Hickson 2012-01-25 23:45:02 UTC
*** Bug 14693 has been marked as a duplicate of this bug. ***
Comment 15 Julian Reschke 2012-01-26 08:16:47 UTC
Please keep this bug open until the text it is about is indeed gone.
Comment 16 Sam Ruby 2012-11-26 11:00:02 UTC
This needs to be resolved prior to entrance to CR.  See also http://lists.w3.org/Archives/Public/public-html/2012Nov/0201.html
Comment 17 Robin Berjon 2012-11-27 15:48:53 UTC
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.
Comment 18 Robin Berjon 2013-01-21 15:59:22 UTC
Mass move to "HTML WG"
Comment 19 Robin Berjon 2013-01-21 16:02:08 UTC
Mass move to "HTML WG"
Comment 20 Erika Doyle Navara 2013-02-06 23:47:25 UTC
Reviving discussion for this on public-html:

http://lists.w3.org/Archives/Public/public-html/2013Feb/0069.html
Comment 21 Erika Doyle Navara 2013-02-18 23:30:04 UTC
Reassigning to Silvia, to cherry-pick from the WHATWG spec:

https://github.com/w3c/html/commit/5eba22bd9dfec1295f6108e002d3a3a157287767
Comment 22 Erika Doyle Navara 2013-03-04 23:52:03 UTC
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:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
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)
Rationale: 

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:

https://github.com/w3c/html/commit/b2e4d7e252df4c1be9e71666ec794ab0b2fa3a3e

Going forward, bugs in URL parsing should be filed on that spec.
Comment 23 Masatoshi Kimura 2013-04-11 15:51:18 UTC
This is actually WONTFIX because WHATWG specs WONTFIXed the corresponding bug 15684.