- From: Fumitoshi Ukai <ukai@chromium.org>
- Date: Fri, 4 Dec 2009 15:05:08 +0900
On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: > > > > Currently, the Web Sockets API spec says that the WebSocket.URL > > attribute must just return a value that was passed to the WebSocket > > constructor. This doesn't match how many other url accessors work, and > > consequentially, it doesn't match what currently happens in WebKit. > > > > I think it makes more sense to return a resolved URL - e.g. (new > > WebSocket("ws://host/path/../")).URL would return "ws://host/". > > I've changed the spec to say that the .URL attribute must return the same > string as is actually used by the protocol spec (i.e. post-resolve). > Whether this does "../" resolution will depend on what the IRI specs end > up saying when we switch to relying on those. > Should (new WebSocket("ws://host/path#frag")).URL be "ws://host/path" rather than "ws://host/path#frag" ? It seems "Resolving Web addresses" will drop fragment component according to http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it. -- ukai > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091204/c6e318b7/attachment.htm>
Received on Thursday, 3 December 2009 22:05:08 UTC