17772 2012-07-13 18:30:39 +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-12-21 14:37:51 +0000 1 1 1 Unclassified WHATWG URL unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#absolute-url P3 normal Unsorted 10213 1 contributor annevk adrianba annevk bzbarsky ian julian.reschke mike public-html-admin public-html-wg-issue-tracking public-webapps w3c sideshowbarker+urlspec oldest_to_newest 69947 0 contributor 2012-07-13 18:30:39 +0000 This was was cloned from bug 10213 as part of operation convergence. Originally filed: 2010-07-20 20:37:00 +0000 ================================================================================ #0 contributor@whatwg.org 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 ================================================================================ #1 Simon Pieters 2010-07-20 21:34:35 +0000 -------------------------------------------------------------------------------- Changing component so Hixie sees this while working on websockets. ================================================================================ #2 Ian 'Hixie' Hickson 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? ================================================================================ #3 Boris Zbarsky 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. ================================================================================ #4 Ian 'Hixie' Hickson 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. ================================================================================ #5 Adam Barth 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. ================================================================================ #6 Ian 'Hixie' Hickson 2011-05-24 20:24:47 +0000 -------------------------------------------------------------------------------- This is now a problem with the WebSocket protocol spec. ================================================================================ #7 Adrian Bateman [MSFT] 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. ================================================================================ #8 Boris Zbarsky 2011-07-07 22:43:47 +0000 -------------------------------------------------------------------------------- That would be inconsistent with how URIs are handled elsewhere in the web platform... ================================================================================ #9 Ian 'Hixie' Hickson 2011-07-08 20:05:50 +0000 -------------------------------------------------------------------------------- This is a generic platform bug, so I'm moving it out of the WebSockets bucket. ================================================================================ 69954 1 annevk 2012-07-13 18:59:34 +0000 The URL specification needs to define this. This is part of the reason why we need a whitelist of hierarchical schemes I think (as most browsers appear to have). 71589 2 annevk 2012-07-27 06:27:03 +0000 *** Bug 10213 has been marked as a duplicate of this bug. *** 71596 3 julian.reschke 2012-07-27 08:28:23 +0000 (In reply to comment #1) > The URL specification needs to define this. This is part of the reason why we > need a whitelist of hierarchical schemes I think (as most browsers appear to > have). It would be good if we had concrete data on which UAs do this, and what for. 71610 4 bzbarsky 2012-07-27 14:37:46 +0000 Gecko certainly does, in the form of its set of registered nsIProtocolHandlers, which are what decide how a URI is parsed. Unknown schemes get handed over to a protocol handler that assume a non-hierarchical URI. 74778 5 annevk 2012-09-28 10:43:56 +0000 http://url.spec.whatwg.org/ defines this behaviour now and makes browsers' behavior for ws/wss conforming. All that is left here is updating the WebSocket API to refer to the new URL standard.