- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 04 Jul 2011 16:13:05 +0200
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/
Received on Monday, 4 July 2011 07:13:05 UTC