- From: jugglinmike <web-platform-tests-notifications@w3.org>
- Date: Mon, 13 Mar 2017 15:04:28 GMT
- To: public-web-platform-tests-notifications@w3.org
> I don't think this patch is valid, since we want in fact be testing 204/205 > responses with bodies. Oh, okay. I have to admit that even after 2 weeks of working with this test, this was not apparent to me. If the intent is to test the behavior with invalid responses, then I'd like to create a standalone test that explicitly describes that condition. However, we won't be able to do this until we've resolved the bug I've described above. > What exactly happens with the second TCP packet? If the connection is still > open, Chrome should be able to handle it. Otherwise Chrome should have closed > the connection early or some such. If the connection is still open, Chrome tolerates the extra data (although the the difference between "accept" and "reject" from the "fetch" spec does not seem to be appreciable here, since [the `EventSource` spec dictates failure for all non-200 responses](https://html.spec.whatwg.org/multipage/comms.html#sse-processing-model)). The problem with the infrastructure is only appreciable when Chrome *closes* the connection. It does this (quite reasonably) if when the HTTP 204/205 response is segmented at the end of the headers. But in this case, if WPT's server continues to write to the connection, the data is sent as the response to some other request. That is what [the branch I've shared](https://github.com/w3c/web-platform-tests/compare/master...bocoup:serve-bug-demo) is intended to demonstrate. View on GitHub: https://github.com/w3c/web-platform-tests/pull/5037#issuecomment-286134679
Received on Monday, 13 March 2017 15:04:40 UTC