Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Bjoern Hoehrmann]

* Simon Pieters wrote:
>Workers ignore the MIME type.

Yes, this thread was initially about the problems that causes.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Simon Pieters]

On Fri, 18 Nov 2011 14:10:36 +0100, Julian Reschke   
wrote:



Why not? We have context-dependent treatment of MIME types already (e.g.
a text/html resource can be treated as a script).


These are workarounds because of legacy, I assume. Workers are a new  
feature.


Workers ignore the MIME type.

--
Simon Pieters
Opera Software

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Julian Reschke]

On 2011-11-18 14:04, Simon Pieters wrote:

On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke
 wrote:


That's fine if you use a new type, or profile an existing one.

But claiming that charset=... means something else before depending on
the context it's used in is asking for trouble.


What kind of trouble?


Trouble that other recipients disagree on that the encoding is.


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and
character escapes. AFAIK there's have been no requests to support legacy
encodings in workers in Opera.


I'm ok with that. I'm not ok with treating something that has a
charset of ISO-8859-1 silently as UTF-8, in particular when other
parts of the platform disagree.


Why not? We have context-dependent treatment of MIME types already (e.g.
a text/html resource can be treated as a script).


These are workarounds because of legacy, I assume. Workers are a new 
feature.


Best regards, Julian

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Simon Pieters]

On Fri, 18 Nov 2011 13:46:16 +0100, Julian Reschke   
wrote:



That's fine if you use a new type, or profile an existing one.

But claiming that charset=... means something else before depending on  
the context it's used in is asking for trouble.


What kind of trouble?


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and
character escapes. AFAIK there's have been no requests to support legacy
encodings in workers in Opera.


I'm ok with that. I'm not ok with treating something that has a charset  
of ISO-8859-1 silently as UTF-8, in particular when other parts of the  
platform disagree.


Why not? We have context-dependent treatment of MIME types already (e.g. a  
text/html resource can be treated as a script).


--
Simon Pieters
Opera Software

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Julian Reschke]

On 2011-11-18 13:44, Simon Pieters wrote:

On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke
 wrote:


On 2011-11-18 13:03, Simon Pieters wrote:

UTF-8-only for workers is deliberate. I don't see any reason to reject
scripts that have other charset. Rejecting the script would mean that
some authors can't use workers at all because their server uses charset
and they can't change it.


What kind of server sets a charset on JS *and* cannot be configured
not to?


I don't know. I know we changed appcache to not do MIME type checking of
the cache manifest because authors had trouble changing it. I know we
sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and
text/plain; charset=UTF-8 because it's the default in some servers.


And, if this is the case, isn't this a good reason to actually require
that the charset is handled correctly?


For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT,
workers).


That's fine if you use a new type, or profile an existing one.

But claiming that charset=... means something else before depending on 
the context it's used in is asking for trouble.



I really believe that piling up workarounds and inconsistencies like
these makes the whole platform much harder to use than necessary.


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and
character escapes. AFAIK there's have been no requests to support legacy
encodings in workers in Opera.


I'm ok with that. I'm not ok with treating something that has a charset 
of ISO-8859-1 silently as UTF-8, in particular when other parts of the 
platform disagree.


Best regards, Julian

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Simon Pieters]

On Fri, 18 Nov 2011 13:22:42 +0100, Julian Reschke   
wrote:



On 2011-11-18 13:03, Simon Pieters wrote:

UTF-8-only for workers is deliberate. I don't see any reason to reject
scripts that have other charset. Rejecting the script would mean that
some authors can't use workers at all because their server uses charset
and they can't change it.


What kind of server sets a charset on JS *and* cannot be configured not  
to?


I don't know. I know we changed appcache to not do MIME type checking of  
the cache manifest because authors had trouble changing it. I know we  
sniff text/plain; charset=iso-8859-1, text/plain; charset=ISO-8859-1 and  
text/plain; charset=UTF-8 because it's the default in some servers.


And, if this is the case, isn't this a good reason to actually require  
that the charset is handled correctly?


For new features, we try to force UTF-8 (e.g. cache manifest, WebVTT,  
workers).


I really believe that piling up workarounds and inconsistencies like  
these makes the whole platform much harder to use than necessary.


Just use UTF-8. If you can't use UTF-8 in your workers, use ASCII and  
character escapes. AFAIK there's have been no requests to support legacy  
encodings in workers in Opera.


--
Simon Pieters
Opera Software

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Simon Pieters]

On Fri, 18 Nov 2011 13:03:03 +0100, Boris Zbarsky  wrote:


On 11/19/11 12:52 AM, Julian Reschke wrote:

 says.


For what it's worth, Gecko's worker loading code runs the same algorithm  
to determine the charset as the algorithm used for 

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Julian Reschke]

On 2011-11-18 13:03, Simon Pieters wrote:

UTF-8-only for workers is deliberate. I don't see any reason to reject
scripts that have other charset. Rejecting the script would mean that
some authors can't use workers at all because their server uses charset
and they can't change it.


What kind of server sets a charset on JS *and* cannot be configured not to?

And, if this is the case, isn't this a good reason to actually require 
that the charset is handled correctly?


I really believe that piling up workarounds and inconsistencies like 
these makes the whole platform much harder to use than necessary.


Best regards, Julian

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Boris Zbarsky]

On 11/19/11 12:52 AM, Julian Reschke wrote:

 says.


For what it's worth, Gecko's worker loading code runs the same algorithm 
to determine the charset as the algorithm used for 

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Simon Pieters]

On Fri, 18 Nov 2011 12:52:36 +0100, Julian Reschke   
wrote:



If Gecko does that for Workers, that would be a bug. Workers are UTF-8
only.


If you are saying that

Content-Type: application/javascript;charset=iso-8859-1

... 0xC3 0xB6 ...

should have U+00C3 U+00B6 when used via

Re: Firefox bug: "Worker" load ignores Content-Type version parameter

[Julian Reschke]

On 2011-11-18 12:36, Julian Reschke wrote:

On 2011-11-18 12:29, Bjoern Hoehrmann wrote:

* Anne van Kesteren wrote:

On Fri, 18 Nov 2011 09:32:22 +0100, Julian
Reschke
wrote:

I recently started looking at FF's Content-Type related code. As far as
I can tell, there are at least two code paths, one taken for the HTTP
header field, one for HTML media type attributes. There may be more.

The HTTP code definitively only processes the charset parameter.


If Gecko does that for Workers, that would be a bug. Workers are UTF-8
only.


If you are saying that

Content-Type: application/javascript;charset=iso-8859-1

... 0xC3 0xB6 ...

should have U+00C3 U+00B6 when used via