Closed Bug 869878 Opened 11 years ago Closed 11 years ago

[eventsource] When encoding charset=windows-1252, Firefox goes to onmessage() but not onerror().

Categories

(Firefox :: Untriaged, defect)

23 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: tina.zhao, Assigned: wfernandom2004)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.10 (KHTML, like Gecko) Chrome/23.0.1262.0 Safari/537.10

Steps to reproduce:

ServerSentEvent latest Editor's Draft 23 April 2013 (http://dev.w3.org/html5/eventsource/) test
- Test wiki: http://www.w3.org/wiki/Webapps/Interop/ServerSentEvents
- 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


Actual results:

Test case failed:
In Spec, Event streams in this format must always be encoded as UTF-8. But when sending the source:
var source = new EventSource("resources/message.php?mime=text/event-stream;charset=windows-1252&message=data%3A%E2%80%A6")
It goes to the source.onmessage(), throws assert_unreached: Reached unreachable code


Expected results:

It should go to source.onerror().
See Also: → 869432
Summary: [eventsource] When encoding charset=windoes-1252, Firefox goes to onmessage() but not onerror(). → [eventsource] When encoding charset=windows-1252, Firefox goes to onmessage() but not onerror().
I couldn't find a sentence saying something like "user agents must fire an error event if the charset parameter is present and the value is not utf-8" in the spec.
I thought user agents would decode Event streams in utf-8 regardless of the meaningless charset parameter.
Please, clarify if this is really an issue or not. As Masatoshi Kimura wrote above, the spec does not require to fire the error event. 

Except if the tech spec is updated, I would conclude this bug stating that the test case is wrong and, in this case, it should be corrected to make Mozilla and Opera implementations to pass and to make Chrome implementation to fail.
Flags: needinfo?(ian)
Flags: needinfo?(bugs)
Assignee: nobody → wfernandom2004
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
tinazhao: See comment 2.
Flags: needinfo?(tina.zhao)
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Yeah, I agree, nothing in the spec requires firing error.
Flags: needinfo?(bugs)
See Also: → 662073
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
See Also: 869432
Sorry for the late reply...

The Spec describes that“Event streams in this format must always be encoded as UTF-8”, so my understanding is if the event streams doesn't encode as UTF-8, there should be an error.

(In reply to Wellington Fernando de Macedo from comment #2)
> Please, clarify if this is really an issue or not. As Masatoshi Kimura wrote
> above, the spec does not require to fire the error event. 
> 
> Except if the tech spec is updated, I would conclude this bug stating that
> the test case is wrong and, in this case, it should be corrected to make
> Mozilla and Opera implementations to pass and to make Chrome implementation
> to fail.
Flags: needinfo?(tina.zhao)
(In reply to tinazhao from comment #5)
> The Spec describes that“Event streams in this format must always be encoded
> as UTF-8”, so my understanding is if the event streams doesn't encode as
> UTF-8, there should be an error.

Does it mean "if the sequence in the stream is invalid as UTF-8"? Or "if the charset parameter says that the sequence is not encoded in UTF-8"? I think this is the former because charset parameter has no meanings, as the spec is saying.
Hmm...Make sense, unreached is better then onerror in this case. This test case should be updated.
(In reply to tinazhao from comment #7)
> Hmm...Make sense, unreached is better then onerror in this case. This test
> case should be updated.

Tina - given your conclusion, would you please submit a PullRequest that fixes the test case bug?

-Thanks, Art Barstow
It's better to restrict it.

As Yaffle pointed out in the GitHub pull request (https://github.com/w3c/web-platform-tests/pull/268), the spec says:

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

http://dev.w3.org/html5/eventsource/#text-event-stream


Also, the whole reason for this force-utf8 is to disallow craziness on the web. Always having to use utf8 but allowing you to set charset=whatever kinda gives mixed signals. The test is correct, the implementation wrong. IMHO :)
the spec still doesn't require firing error. It does say the value should be utf-8 but it also has
no purpose. So I interpret the value is authoring requirement, and the implementation is correct.
Agreed.
Status: RESOLVED → VERIFIED
Flags: needinfo?(ian)
You need to log in before you can comment on or make changes to this bug.