[whatwg] EventSource - Handling a charset in the content-type header
harald at alvestrand.no
Thu Mar 24 05:36:33 PDT 2011
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 , 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 .
>> 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 .
> 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....
>>  https://bugs.webkit.org/show_bug.cgi?id=45372
>>  https://bugs.webkit.org/show_bug.cgi?id=45372#c30
>>  http://dev.w3.org/html5/spec/offline.html#writing-cache-manifests
More information about the whatwg