12543 2011-04-23 01:28:20 +0000 [URL] Replacing backslash with forward slash in URIs doesn't seem to be necessitated by web compat 2013-04-11 15:51:18 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.w3.org/Bugs/Public/show_bug.cgi?id=14693 http://www.whatwg.org/specs/web-apps/current-work/#resolving-urls P3 normal --- 15684 1 contributor silviapfeiffer1 brunoaiss bzbarsky erika.doyle ian julian.reschke mike public-html-admin public-html-wg-issue-tracking robin rubys travil VYV03354 w3c public-html-bugzilla oldest_to_newest 47619 0 contributor 2011-04-23 01:28:20 +0000 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 47620 1 bzbarsky 2011-04-23 01:29:52 +0000 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. 47621 2 w3c 2011-04-23 02:58:13 +0000 This surprises me. Does Gecko support \ in file URLs on Windows? 47627 3 bzbarsky 2011-04-23 03:31:48 +0000 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. 47630 4 VYV03354 2011-04-23 04:00:38 +0000 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. 50121 5 annevk 2011-06-22 21:48:04 +0000 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. 53936 6 mike 2011-08-04 05:34:38 +0000 mass-move component to LC1 60186 7 mike 2011-11-20 14:35:14 +0000 (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? 60239 8 w3c 2011-11-20 18:18:27 +0000 > Adam? Any plan to update the URL draft to address this? I'm not planning to update that draft anytime soon. 60258 9 mike 2011-11-20 21:00:46 +0000 un-assigning Adam for this per comment #8 60801 10 ian 2011-12-02 17:57:05 +0000 Does anyone know if we have a component for URL spec issues? Or any other tracking mechanism? 60885 11 mike 2011-12-03 05:07:40 +0000 (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 63030 12 mike 2012-01-24 01:17:05 +0000 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. 63129 13 ian 2012-01-25 23:44:06 +0000 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 63131 14 ian 2012-01-25 23:45:02 +0000 *** Bug 14693 has been marked as a duplicate of this bug. *** 63148 15 julian.reschke 2012-01-26 08:16:47 +0000 Please keep this bug open until the text it is about is indeed gone. 78821 16 rubys 2012-11-26 11:00:02 +0000 This needs to be resolved prior to entrance to CR. See also http://lists.w3.org/Archives/Public/public-html/2012Nov/0201.html 78916 17 robin 2012-11-27 15:48:53 +0000 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. 81717 18 robin 2013-01-21 15:59:22 +0000 Mass move to "HTML WG" 81835 19 robin 2013-01-21 16:02:08 +0000 Mass move to "HTML WG" 82667 20 erika.doyle 2013-02-06 23:47:25 +0000 Reviving discussion for this on public-html: http://lists.w3.org/Archives/Public/public-html/2013Feb/0069.html 83293 21 erika.doyle 2013-02-18 23:30:04 +0000 Reassigning to Silvia, to cherry-pick from the WHATWG spec: https://github.com/w3c/html/commit/5eba22bd9dfec1295f6108e002d3a3a157287767 83970 22 erika.doyle 2013-03-04 23:52:03 +0000 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. 85947 23 VYV03354 2013-04-11 15:51:18 +0000 This is actually WONTFIX because WHATWG specs WONTFIXed the corresponding bug 15684.