W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] URL encoding for XHR and Workers.

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 9 Mar 2009 17:02:09 -0700
Message-ID: <63df84f0903091702l73dcbcb9l1c62d8a1dd7ecdb0@mail.gmail.com>
On Fri, Mar 6, 2009 at 4:51 PM, Dmitry Titov <dimich at chromium.org> wrote:
> Hi,
> 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.

/ Jonas
Received on Monday, 9 March 2009 17:02:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:10 UTC