This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22997 - Better to have a clear statement: firing error or not, if Event streams doesn't encode as UTF-8 format.
Summary: Better to have a clear statement: firing error or not, if Event streams doesn...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Server-Sent Events (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-18 02:46 UTC by tinazhao
Modified: 2013-09-12 20:04 UTC (History)
5 users (show)

See Also:

Attachments

Description tinazhao 2013-08-18 02:46:39 UTC 
Steps to reproduce:
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

At present, the implementaion on Chrome and Opera browser is if event streams doesn't encode as UTF-8, the test case jumps to onerror(). But on Firefox, it only assert unreached instead of firing error.
Better to add a statement to let audience know whether firing error is the expected behavior.

- Test suite: https://github.com/w3c/web-platform-tests/tree/master/eventsource
- Test case: https://github.com/w3c/web-platform-tests/blob/master/eventsource/format-utf-8.htm

Spec Info: Server-Sent Events Candidate Recommendation 11 December 2012  (http://www.w3.org/TR/2012/CR-eventsource-20121211/ ).
Spec Description:
"Event streams in this format must always be encoded as UTF-8."
Comment 1 Anne 2013-08-18 10:16:19 UTC 
The user agent requirements of the specification make it pretty clear there should be no error event and it should just work fine.
Comment 2 tinazhao 2013-08-19 01:03:08 UTC 
(In reply to comment #1)
> The user agent requirements of the specification make it pretty clear there
> should be no error event and it should just work fine.

OK, then if it jumps to onerror(), the implementation is wrong and the test case should be FAIL.
Comment 3 Ian 'Hixie' Hickson 2013-08-20 17:52:14 UTC 
I don't understand what part of the spec you think is unclear here. Can you elaborate?
Comment 4 Olli Pettay 2013-08-20 22:08:02 UTC 
https://bugzilla.mozilla.org/show_bug.cgi?id=869878 has some background for this.
Comment 5 Ian 'Hixie' Hickson 2013-09-12 20:04:37 UTC 
The spec says:

#  Event streams in this format must always be encoded as UTF-8.

#  Streams must be decoded using the UTF-8 decode algorithm.

..and of the "charset" parameter:

# The parameter's value must be "utf-8". This parameter serves no purpose; it
# is only allowed for compatibility with legacy servers

I don't really know how else to say this.

Nothing in the spec mentions firing 'error' for EventSource if the charset="" is wrong (not UTF-8). In fact it explicitly says:

# HTTP 200 OK responses with a Content-Type header specifying the type
# text/event-stream, ignoring any MIME type parameters, must be processed
# line by line as described below.

(Notice the part that says "ignoring any MIME type parameters".)

I've added yet more text to the intro, just in case, but...
Comment 6 contributor 2013-09-12 20:04:52 UTC 
Checked in as WHATWG revision r8178.
Check-in comment: Try to be even clearer...
http://html5.org/tools/web-apps-tracker?from=8177&to=8178