This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10213 - [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...
Summary: [URL] The definition of "absolute url" makes https:foo not an absolute url, s...
Status: RESOLVED DUPLICATE of bug 17772
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on: 17772
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-20 20:37 UTC by contributor
Modified: 2012-07-27 06:27 UTC (History)
9 users (show)

See Also:


Attachments

Description contributor 2010-07-20 20:37:20 UTC
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
Comment 1 Simon Pieters 2010-07-20 21:34:35 UTC
Changing component so Hixie sees this while working on websockets.
Comment 2 Ian 'Hixie' Hickson 2010-07-22 05:39:43 UTC
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?
Comment 3 Boris Zbarsky 2010-07-22 05:50:07 UTC
> 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.
Comment 4 Ian 'Hixie' Hickson 2010-08-13 07:31:20 UTC
I would like to make this Adam's problem. Not sure what the status of his URL work is right now.
Comment 5 Adam Barth 2010-08-13 16:39:54 UTC
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.
Comment 6 Ian 'Hixie' Hickson 2011-05-24 20:24:47 UTC
This is now a problem with the WebSocket protocol spec.
Comment 7 Adrian Bateman [MSFT] 2011-07-07 21:45:28 UTC
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.
Comment 8 Boris Zbarsky 2011-07-07 22:43:47 UTC
That would be inconsistent with how URIs are handled elsewhere in the web platform...
Comment 9 Ian 'Hixie' Hickson 2011-07-08 20:05:50 UTC
This is a generic platform bug, so I'm moving it out of the WebSockets bucket.
Comment 10 contributor 2012-07-13 18:30:43 UTC
This bug was cloned to create bug 17772 as part of operation convergence.
Comment 11 Ian 'Hixie' Hickson 2012-07-26 23:32:10 UTC
Anne, is this your problem now?
Comment 12 Anne 2012-07-27 06:27:03 UTC
Yeah, already reassigned the original.

*** This bug has been marked as a duplicate of bug 17772 ***
Comment 13 Anne 2012-07-27 06:27:36 UTC
Euh, the clone. Oops :-)