- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 03 Nov 2011 16:07:20 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: Ian Hickson <ian@hixie.ch>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On 2011-11-02 20:02, Anne van Kesteren wrote: > On Wed, 02 Nov 2011 11:59:14 -0700, Julian Reschke > <julian.reschke@gmx.de> wrote: >> On 2011-11-02 19:46, Anne van Kesteren wrote: >>> If you are confused about the terms, they are defined in HTML. >> >> But they aren't linked, as far as I can tell. It would be good if they >> were, and then we can review that text again. > > They are in > > http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#parsing-websocket-urls > > > so you can use that for review. > ... OK, I have tried to understand what's going on here, but I largely failed. 0) The algorithm "Resolve the url string" doesn't exist in the spec, nor does it reference anything. If nobody has complained about this yet then my conclusion is that nobody has read that section. Not surprisingly, as it was added past last-call. 1) Anne explains that it's supposed to reference <http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#resolve-a-url>, so that change should be made. 2) Assuming that change *will* be made...: the difference to what the protocol spec says seems to be... 2a) it deals with IRIs (converting them to URIs), 2b) it specifies certain fixup operations for broken input, such as converting \ to /, which, last time I checked, were controversial even among browser implementers. Reminder: this was a past-LC change. I think I'm not asking too much when I'm asking for a precise explanation of what the rational for this change was. Best regards, Julian
Received on Thursday, 3 November 2011 15:14:44 UTC