Bug 119974 - [eventsource] If there is a network error, the readyState of eventsource got CONNECTING but not CLOSED.
Summary: [eventsource] If there is a network error, the readyState of eventsource got ...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-18 00:40 PDT by tinazhao
Modified: 2014-04-14 12:35 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tinazhao 2013-08-18 00:40:28 PDT
[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.
Comment 1 Arthur Barstow 2014-04-09 13:27:52 PDT
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
Comment 2 Alexey Proskuryakov 2014-04-10 10:54:52 PDT
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."
Comment 3 Arthur Barstow 2014-04-14 11:44:37 PDT
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
Comment 4 Alexey Proskuryakov 2014-04-14 12:35:35 PDT
Thanks. Perhaps we need a separate bug about that, as CORS error is not a network error (I think?)