Re: [eventsource-tests] [eventsource] Do not send invalid HTTP response (#5037)

> 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