Bug 119974
Summary: | [eventsource] If there is a network error, the readyState of eventsource got CONNECTING but not CLOSED. | ||
---|---|---|---|
Product: | WebKit | Reporter: | tinazhao <tina.zhao> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED | ||
Severity: | Normal | CC: | afbarstow, ap, zhiqiang.zhang |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
tinazhao
[ServerSentEvent]
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Steps to reproduce:
According to the spec description, if there is a network error, the readyState is expected as 2 (CLOSED).
Spec Info: Server-Sent Events Candidate Recommendation 11 December 2012 (http://www.w3.org/TR/2012/CR-eventsource-20121211/ ).
Spec Description:
"CLOSED (numeric value 2)
The connection is not open, and the user agent is not trying to reconnect. Either there was a fatal error or the close() method was invoked."
- Test wiki: http://www.w3.org/wiki/Webapps/Interop/ServerSentEvents
- Test suite: https://github.com/w3c/web-platform-tests/tree/master/eventsource
- Test case: http://w3c-test.org/web-platform-tests/master/eventsource/shared-worker/eventsource-constructor-non-same-origin.htm
Actual results:
Assersion failed: assert_equals: source.readyState expected 2-CLOSED but got 0-CONNECTING.
This test Failed on Chrome 28.0.1500.95 m, got PASS on Opera Next 12.16
Expected results:
In this case, readyState is expected 2-CLOSED.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Arthur Barstow
The URL of the test case in the original comment is now wrong. The test case is now https://github.com/w3c/web-platform-tests/blob/master/eventsource/eventsource-constructor-non-same-origin.htm
The test case can be run via a browser (at least today) via:
http://w3c-test.org/eventsource/eventsource-constructor-non-same-origin.htm
Alexey Proskuryakov
Could you please elaborate why this is a WebKit bug? Both failing tests try connecting to https://example.not/test, and expect CLOSED state.
But the current editor's draft even gives it as an example that "Network errors that prevents the connection from being established in the first place (e.g. DNS errors), must cause the user agent to asynchronously reestablish the connection."
Arthur Barstow
Alexey - I screwed up the URL in comment #1 - the updated URL I provided actually passes.
Although Tina or Zhiqiang should be able to confirm, there are two tests that fail and here are there new URLS:
1. http://w3c-test.org/eventsource/dedicated-worker/eventsource-constructor-non-same-origin.htm
2. http://w3c-test.org/eventsource/shared-worker/eventsource-constructor-non-same-origin.htm
FYI, there was a discussion thread about these two test files in August 2013: http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Aug/0009.html
Alexey Proskuryakov
Thanks. Perhaps we need a separate bug about that, as CORS error is not a network error (I think?)