Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upEventSource constructor enters wrong readyState on non-same-origin urls with non-http(s) schemes #25692
Comments
|
It turns out the tests are expecting a "may" behavior here, but a very sensible "may" behavior that's easy to do ("cause the user agent to reestablish the connection in parallel, unless the user agent knows that to be futile, in which case the user agent may fail the connection.") |
|
web-platform-tests/wpt#4311 Possibly this should be a wontfix and we should actually instead make the tests less picky. |
bors-servo
added a commit
that referenced
this issue
Feb 10, 2020
Let EventSource fail fast on bad schemes <!-- Please describe your changes on the following line: --> EventSource went into an infinite reconnect loop in some cases where tests wanted it to go into a hard error state; this addresses the cases where that happens because the url isn't even http(s) and will thus definitely never result in an event stream. web-platform-tests/wpt#4311 suggests the tests might just be too picky here; the spec does use the word "may" on relevant behavior. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #25692 <!-- Either: --> - [X] There are tests for these changes <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo
added a commit
that referenced
this issue
Feb 11, 2020
Let EventSource fail fast on bad schemes <!-- Please describe your changes on the following line: --> EventSource went into an infinite reconnect loop in some cases where tests wanted it to go into a hard error state; this addresses the cases where that happens because the url isn't even http(s) and will thus definitely never result in an event stream. web-platform-tests/wpt#4311 suggests the tests might just be too picky here; the spec does use the word "may" on relevant behavior. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #25692 <!-- Either: --> - [X] There are tests for these changes <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo
added a commit
that referenced
this issue
Feb 11, 2020
Filter file: and about: responses opaquely <!-- Please describe your changes on the following line: --> file: and about: schemes were being treated like data: for cors purposes, when in fact they should have been subject to opaque response filtering. A comment indicated that this was necessary for some CSS tests, but I think the comment was out of date; the only tests depending on the unfiltered responses are unit tests that do not test any CSS functionality. I've updated those tests to now test for the opaque-filtering itself. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #25686 <!-- Either: --> - [X] There are tests for these changes, but also some loss of unit test coverage (#25693) and a newly failing test case (#25692) <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo
added a commit
that referenced
this issue
Feb 11, 2020
Filter file: and about: responses opaquely <!-- Please describe your changes on the following line: --> file: and about: schemes were being treated like data: for cors purposes, when in fact they should have been subject to opaque response filtering. A comment indicated that this was necessary for some CSS tests, but I think the comment was out of date; the only tests depending on the unfiltered responses are unit tests that do not test any CSS functionality. I've updated those tests to now test for the opaque-filtering itself. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #25686 <!-- Either: --> - [X] There are tests for these changes, but also some loss of unit test coverage (#25693) and a newly failing test case (#25692) <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
eventsource/eventsource-constructor-non-same-origin.htm expects an EventSource with an about, mailto, javascript, etc. url to end up in readyState CLOSED when it throws an error; the error is thrown but the readyState is incorrect.
Multiple cases are failing. One case currently passes by coincidence and will fail when #25687 fixes other behavior.