[whatwg] EventSource - Handling a charset in the content-type header
Anne van Kesteren
annevk at opera.com
Mon Jul 4 07:13:05 PDT 2011
On Thu, 24 Mar 2011 05:52:02 +0100, Julien Chaffraix
<julien.chaffraix at gmail.com> 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/
More information about the whatwg
mailing list