10213 2010-07-20 20:37:20 +0000 [URL] The definition of "absolute url" makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this definition for websockets means that wss: urls with no forward... 2012-07-27 06:27:36 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED DUPLICATE 17772 http://www.whatwg.org/specs/web-apps/current-work/#absolute-url P3 normal Unsorted 17772 1 contributor ian adrianba annevk bzbarsky ian julian.reschke mike public-html-admin public-webapps w3c contributor oldest_to_newest 37024 0 contributor 2010-07-20 20:37:20 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#absolute-url Comment: The definition of "absolute url" makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? In particular, using this definition for websockets means that wss: urls with no forward slashes after the ':' are treated as non-absolute, though in fact they're treated as absolute by the browser in practice. Posted from: 173.48.34.3 37028 1 zcorpan 2010-07-20 21:34:35 +0000 Changing component so Hixie sees this while working on websockets. 37059 2 ian 2010-07-22 05:39:43 +0000 ws:foo isn't absolute, therefore per spec it's treated as non-absolute. Am I missing something? Are browsers not implementing the spec here? 37061 3 bzbarsky 2010-07-22 05:50:07 +0000 > ws:foo isn't absolute, How is a browser supposed to know that? Trying to create a URI from that string without a base URI successfully creates one, for example... > Are browsers not implementing the spec here? Nope. Neither Gecko nor webkit throw on such a url, for example. In Gecko's case, because the concept of "absolute url" the spec uses (one which resolves to different things depending on the base) matches nothing that Necko exposes, and because by the definition normally used in Gecko (it's an absolute URL if you can parse it as a url even if there is no base) this url is absolute. See also https://bugzilla.mozilla.org/show_bug.cgi?id=580234 which is what prompted me to read this section to start with. 37390 4 ian 2010-08-13 07:31:20 +0000 I would like to make this Adam's problem. Not sure what the status of his URL work is right now. 37409 5 w3c 2010-08-13 16:39:54 +0000 Happy for this to be my problem. The state of the URL work is that I have lots of data to crunch and I need to sit down with a big pot of coffee and crunch it. 48749 6 ian 2011-05-24 20:24:47 +0000 This is now a problem with the WebSocket protocol spec. 50800 7 adrianba 2011-07-07 21:45:28 +0000 Section 3 of the protocol spec (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-3) shows the valid syntax for a ws-URI. We believe the API should throw a SYNTAX_ERR if the address supplied does not match this format. 50806 8 bzbarsky 2011-07-07 22:43:47 +0000 That would be inconsistent with how URIs are handled elsewhere in the web platform... 50848 9 ian 2011-07-08 20:05:50 +0000 This is a generic platform bug, so I'm moving it out of the WebSockets bucket. 69948 10 contributor 2012-07-13 18:30:43 +0000 This bug was cloned to create bug 17772 as part of operation convergence. 71538 11 ian 2012-07-26 23:32:10 +0000 Anne, is this your problem now? 71588 12 annevk 2012-07-27 06:27:03 +0000 Yeah, already reassigned the original. *** This bug has been marked as a duplicate of bug 17772 *** 71590 13 annevk 2012-07-27 06:27:36 +0000 Euh, the clone. Oops :-)