Re: [whatwg] EventSource - Handling a charset in the content-type header
On Mon, 4 Jul 2011, Anne van Kesteren wrote: > I noticed Ian updated the specification, but it seems current > implementations differ quite wildly. E.g. Gecko happily ignores > > Content-Type: text/event-stream;charset=tralala > > as does Opera instead of closing the connection. Chrome bites, but happily > ignores > > Content-Type: text/event-stream;tralala > > along with Opera and Gecko. Safari 5.0.5 bites on that however and also on > charset=tralala. All browsers seem to allow (note the trailing semi-colon): > > Content-Type: text/event-stream; > > Are we sure we want this strict checking of media type parameters? I > always thought the media type itself was what strict checking should be > done upon, but that its parameters were extension points, not points of > failure. Fair enough. I've changed the spec to ignore parameters on text/event-stream. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] EventSource - Handling a charset in the content-type header
On 2011-07-04 16:13, Anne van Kesteren wrote: ... Are we sure we want this strict checking of media type parameters? I always thought the media type itself was what strict checking should be done upon, but that its parameters were extension points, not points of failure. ... The right thing for consistency with other uses of media types is to ignore unknown parameters. Best regards, Julian
Re: [whatwg] EventSource - Handling a charset in the content-type header
On Thu, 24 Mar 2011 05:52:02 +0100, Julien Chaffraix wrote: the EventSource specification states the current content-type header should match the string "text/event-stream". However following some bugs opened inside the WebKit project [1], we relaxed the content-type check to ignore any specified charset as it confused developers and can potentially break existing servers that automatically send a charset as part of the response [2]. We are currently revisiting our approach and our current take would be to allow a mime-type of "text/event-stream" with an optional charset="UTF-8". No other charset would be allowed as UTF-8 is the only encoding supported by the standard. I noticed Ian updated the specification, but it seems current implementations differ quite wildly. E.g. Gecko happily ignores Content-Type: text/event-stream;charset=tralala as does Opera instead of closing the connection. Chrome bites, but happily ignores Content-Type: text/event-stream;tralala along with Opera and Gecko. Safari 5.0.5 bites on that however and also on charset=tralala. All browsers seem to allow (note the trailing semi-colon): Content-Type: text/event-stream; Are we sure we want this strict checking of media type parameters? I always thought the media type itself was what strict checking should be done upon, but that its parameters were extension points, not points of failure. [1] https://bugs.webkit.org/show_bug.cgi?id=45372 [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] EventSource - Handling a charset in the content-type header
On Thu, 24 Mar 2011, Ian Hickson wrote: > On Wed, 23 Mar 2011, Julien Chaffraix wrote: > > > > the EventSource specification states the current content-type header > > should match the string "text/event-stream". However following some > > bugs opened inside the WebKit project [1], we relaxed the content-type > > check to ignore any specified charset as it confused developers and > > can potentially break existing servers that automatically send a > > charset as part of the response [2]. > > > > We are currently revisiting our approach and our current take would be > > to allow a mime-type of "text/event-stream" with an optional > > charset="UTF-8". No other charset would be allowed as UTF-8 is the > > only encoding supported by the standard. > > That seems like a reasonable compromise given the legacy servers. > > > We are not set-up on the best way to fix this and would like to reach > > a consensus before correcting our existing behavior so that the > > specification is clarified on this point. Also note that the same > > problem exists for the application cache [3]. > > Thanks for bringing it up. I'll update the spec at some point to mention > that these MIME types are to handled such that a "charset" parameter with > a value that is an ASCII case-insensitive match for the string "utf-8" > should be ignored in determining whether the types are recognised. > > > [1] https://bugs.webkit.org/show_bug.cgi?id=45372 > > [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 > > [3] http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests This is now done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] EventSource - Handling a charset in the content-type header
On 03/24/11 07:14, Ian Hickson wrote: On Wed, 23 Mar 2011, Julien Chaffraix wrote: the EventSource specification states the current content-type header should match the string "text/event-stream". However following some bugs opened inside the WebKit project [1], we relaxed the content-type check to ignore any specified charset as it confused developers and can potentially break existing servers that automatically send a charset as part of the response [2]. We are currently revisiting our approach and our current take would be to allow a mime-type of "text/event-stream" with an optional charset="UTF-8". No other charset would be allowed as UTF-8 is the only encoding supported by the standard. That seems like a reasonable compromise given the legacy servers. We are not set-up on the best way to fix this and would like to reach a consensus before correcting our existing behavior so that the specification is clarified on this point. Also note that the same problem exists for the application cache [3]. Thanks for bringing it up. I'll update the spec at some point to mention that these MIME types are to handled such that a "charset" parameter with a value that is an ASCII case-insensitive match for the string "utf-8" should be ignored in determining whether the types are recognised. RFC 2046 section 4.1.2 seems to indicate that subtypes of "text" can specify that they don't have a "charset" parameter, but if they do, it has to have the same meaning as for text/plain. It seems from the cited experience that some implementors have taken this to mean that "it is always harmless to send a charset parameter". I think the spec might want to state that one can reject all values except "utf-8" (case insensitive) - if a parser gets something that someone passed through a general transcoder and relabelled using the "charset" parameter, it seems likely that the parser won't want to deal with the possibly bogus result of parsing the content. I hope there aren't any such bogosities around [1] https://bugs.webkit.org/show_bug.cgi?id=45372 [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 [3] http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests
Re: [whatwg] EventSource - Handling a charset in the content-type header
On Wed, 23 Mar 2011, Julien Chaffraix wrote: > > the EventSource specification states the current content-type header > should match the string "text/event-stream". However following some > bugs opened inside the WebKit project [1], we relaxed the content-type > check to ignore any specified charset as it confused developers and > can potentially break existing servers that automatically send a > charset as part of the response [2]. > > We are currently revisiting our approach and our current take would be > to allow a mime-type of "text/event-stream" with an optional > charset="UTF-8". No other charset would be allowed as UTF-8 is the > only encoding supported by the standard. That seems like a reasonable compromise given the legacy servers. > We are not set-up on the best way to fix this and would like to reach > a consensus before correcting our existing behavior so that the > specification is clarified on this point. Also note that the same > problem exists for the application cache [3]. Thanks for bringing it up. I'll update the spec at some point to mention that these MIME types are to handled such that a "charset" parameter with a value that is an ASCII case-insensitive match for the string "utf-8" should be ignored in determining whether the types are recognised. > [1] https://bugs.webkit.org/show_bug.cgi?id=45372 > [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 > [3] http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] EventSource - Handling a charset in the content-type header
Hi, the EventSource specification states the current content-type header should match the string "text/event-stream". However following some bugs opened inside the WebKit project [1], we relaxed the content-type check to ignore any specified charset as it confused developers and can potentially break existing servers that automatically send a charset as part of the response [2]. We are currently revisiting our approach and our current take would be to allow a mime-type of "text/event-stream" with an optional charset="UTF-8". No other charset would be allowed as UTF-8 is the only encoding supported by the standard. We are not set-up on the best way to fix this and would like to reach a consensus before correcting our existing behavior so that the specification is clarified on this point. Also note that the same problem exists for the application cache [3]. Thanks, Julien [1] https://bugs.webkit.org/show_bug.cgi?id=45372 [2] https://bugs.webkit.org/show_bug.cgi?id=45372#c30 [3] http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests
