- From: Dmitry Titov <dimich@chromium.org>
- Date: Mon, 9 Mar 2009 11:52:32 -0700
Update:Ian Hixie pointed to places in spec which specify very clearly that all URLs in workers will be encoded in UTF-8 (including query part) before sent over wire regardless of whether it is a new worker, importScripts or XHR URL. The "encoding of the script" is set to UTF-8 as prescribed by Workers spec, section 2.5, step 3. This overrides the 'inherited' encoding from the parent document and even http header for the worker's script. At the same time, HTML5 spec, section 2.5.1 says URL that came from script has encoding of the script. So the FF beta behavior (encode URLs using the encoding of the top-level document that created the first level worker) seems to be incorrect, I plan to file a bug on it. Dmitry On Sat, Mar 7, 2009 at 9:39 AM, Anne van Kesteren <annevk at opera.com> wrote: > On Sat, 07 Mar 2009 00:51:51 +0100, Dmitry Titov <dimich at chromium.org> > wrote: > >> - XmlHttpRequest created on the Page would send its URL to server encoded >> using UTF8, irrespective to the encoding of the Page. However, a >> XmlHttpRequest created in the Worker would send the URL encoded using >> Page's encoding. It seems that either XHR on the Page should also use Page's >> encoding, or XHR in the Worker should use UTF-8. Bug? >> > > I don't see how Web Workers specification overrides UTF-8 here. Admittedly, > XMLHttpRequest does need to be updated to be able to get base URLs not > derived from Window/Document. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090309/c1c94d22/attachment.htm>
Received on Monday, 9 March 2009 11:52:32 UTC