23821 2013-11-14 04:35:39 +0000 The WebSocket constructor resolves the URL using UTF-8, but .url appears to use the document's encoding as URL character encoding. 2013-11-22 07:44:25 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#dom-websocket-url P3 normal Unsorted 1 contributor ian ian mike zcorpan contributor oldest_to_newest 96288 0 contributor 2013-11-14 04:35:39 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#dom-websocket-url Complete: http://www.whatwg.org/c#dom-websocket-url Referrer: Comment: The WebSocket constructor resolves the URL using UTF-8, but .url appears to use the document's encoding as URL character encoding. Posted from: 59.37.57.226 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.26 Safari/537.36 OPR/18.0.1284.11 (Edition Next) 96670 1 contributor 2013-11-21 22:57:57 +0000 Checked in as WHATWG revision r8305. Check-in comment: WebSocket.url should be consistent with how the URL is used in the first place. http://html5.org/tools/web-apps-tracker?from=8304&to=8305 96673 2 ian 2013-11-21 23:29:45 +0000 Note that no browser actually does this per the new spec, currently. Firefox just passes the URL through unmodified (!). Safari and Chrome use the doc encoding for the query component and UTF-8 for the path, converting U+263A in the Win1252 query component into %26%239786%3B. I don't see anything in the URL spec that comes close to this (I don't even see how the path gets %-encoded, actually). 96688 3 zcorpan 2013-11-22 07:44:25 +0000 (In reply to Ian 'Hixie' Hickson from comment #2) > Note that no browser actually does this per the new spec, currently. Presto does, it seems. My copy of Safari also (6.0.4). data:text/html;charset=windows-1252,%3C!DOCTYPE%20html%3E%0A%3Cscript%3Evar%20s%3D%20new%20WebSocket('ws%3A%2F%2Fexample.invalid%2F%3F%5Cu00e5')%3B%20alert(s.url)%20%3C%2Fscript%3E > Firefox just passes the URL through unmodified (!). > Safari and Chrome use the doc encoding for the query component and UTF-8 for > the path, converting U+263A in the Win1252 query component into > %26%239786%3B. I don't see anything in the URL spec that comes close to this It looks like the <form> error handling mode "Otherwise, emit the result of running utf-8 encode on U+0026, U+0023, followed by the shortest sequence of ASCII digits representing c in base ten, followed by U+003B." http://encoding.spec.whatwg.org/#error-handling-mode > (I don't even see how the path gets %-encoded, actually). Do you mean in the spec?