[whatwg] URL encoding for XHR and Workers.
jonas at sicking.cc
Mon Mar 9 17:02:09 PDT 2009
On Fri, Mar 6, 2009 at 4:51 PM, Dmitry Titov <dimich at chromium.org> wrote:
> I have a couple of questions about Web Workers and text encoding of URLs.
> Usually, 'server' and 'path' portions of URLs are always sent in UTRF-8, the
> 'query' portion may be sent encoded if it contains non-ascii characters. I'm
> looking at what should be an encoding used for this.
> Lets say we have the Page that creates a Worker which uses includeScripts to
> load the NestedScript.
> Lets say the Page has some text encoding (from http header, meta tag or
> otherwise). For example, in latest FF nightly (Minefield) the following
> behaviors can be observed:
> - 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?
Sounds like it. Would be great if you could file a bug. That is why we
have beta releases :)
> - When a script of the Worker is decoded, the encoding of the Page is used,
> unless Worker's script comes with http header overriding the ecncoding. That
> sounds right. However, if the Worker in turn creates a nested Worker, uses
> an XHR or importScripts(url), the URL encoding defaults back to the Page's,
> even if there was overriding http header. It might be ok but seems a bit
> illogical - the nested worker or imported scripts are 'sub resources', their
> relative url is resolved against the Worker's base url, so it feels that
> their default encoding should be inherited from Worker. Is it a bug?
I suspect so yes.
More information about the whatwg