[whatwg] Text Encoding used to decode Web Worker's script.

[Dmitry Titov]

It's quite common for the non-English countries to have servers with
Content-Type set for everything textual to specify the local ANSI codepage.
So there are going to be scenarios when there is a JavaScript with text
strings embedded in it, and it can be simply loaded into worker now using
importScripts().
If the Content-Type/charset header is not honored anymore, there will be
cases of silent breakage.

If the script for Workers always required to be modified in some way then
it's much less of a problem. But when a lot of script files can be just
reused, why create a problem for webmasters? Honoring Content-Type override
is not complicated and is already implemented in most browsers, so there
would be an additional work to disable it.

Dmitry


On Thu, Mar 19, 2009 at 4:00 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Mar 19, 2009 at 3:54 PM, Anne van Kesteren <annevk at opera.com>
> wrote:
> > On Thu, 19 Mar 2009 23:49:53 +0100, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >>
> >> The problem is if we want to allow people to use already existing
> >> scripts then they are likely often not in UTF-8.
> >>
> >> Most scripts will probably not work out-of-the box anyway since there
> >> is no access to DOM. But purely computational libraries should work.
> >
> > Would such libraries have a lot of non-UTF-8 characters?
>
> It's the web so yes, I would assume there are some amount of non-UTF-8
> characters. Hard to say how much of course.
>
> > Also, it's not that
> > hard to encode something as UTF-8 these days and the reduced complexity
> > would be a nice benefit.
>
> Do such tools always insert a BOM as well? So that it's safe to reuse
> the script both for <script> and for workers?
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090319/4b352c9d/attachment-0001.htm>