- From: jugglinmike <web-platform-tests-notifications@w3.org>
- Date: Thu, 13 Apr 2017 21:53:29 GMT
- To: public-web-platform-tests-notifications@w3.org
Thanks for the input, @MattMenke. You are correct about my use of a proxy. I mentioned that the OSX and Windows tests were run using BrowserStack-provided browsers connecting to a local server; I just didn't think deeply enough about what that entailed. Communication is indeed mediated by a tunnel in that case, and that indirection invalidates the tests. In order to avoid further confusion, I've struck the invalid data points from my original report. I've conducted a few more tests. This time, I ran them all all tests on a local network, accessing the server directly (i.e. no tunnels, and no `localhost` connections). I also added expanded the trial matrix to include standard and non-standard TCP ports. The topic of "incorrect Content-Length header" seems to be well-worn ground, so I'm focusing on the "extra bytes" tests. (Thanks for the reference, @ericlaw1979 --I've been enjoying reading that post and the associated ones over the last few days.) New tests available here: https://github.com/w3c/web-platform-tests/compare/master...bocoup:http-demo-2 Sigil | Meaning -------------------|-------------------------------------------------- :white_check_mark: | Request completed successfully :x: | Request failed (`net::ERR_INVALID_HTTP_RESPONSE`) :stopwatch: | Request did not resolve Browser | Initial conditions | Port | 0 | 1 | 2 | 3 | 4 | 5 | 6 ------------|----------------------|------|--------------------|--------------------|---------------------|---------------------|--------------------|--------------------|------------------- Chrome 59 | Independent response | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Chrome 59 | Independent response | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: Chrome 59 | Following a 204 | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Chrome 59 | Following a 204 | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: Firefox 55 | Independent response | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Firefox 55 | Independent response | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Firefox 55 | Following a 204 | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: Firefox 55 | Following a 204 | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: Edge 40 | Independent response | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Edge 40 | Independent response | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Edge 40 | Following a 204 | 80 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Edge 40 | Following a 204 | 8080 | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :stopwatch: | :stopwatch: Safari 10.2 | Independent response | 80 | :white_check_mark: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: Safari 10.2 | Independent response | 8080 | :white_check_mark: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: Safari 10.2 | Following a 204 | 80 | :white_check_mark: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: Safari 10.2 | Following a 204 | 8080 | :white_check_mark: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: | :stopwatch: (Integer-labeled columns indicate the number of invalid extra bytes written prior to a valid HTTP 200 response.) Chrome appears to be the only browser to differentiate between standard and non-standard ports. @MattMenke you mentioned that the "response prefixed with 5 invalid bytes" would produce a successful request on port 80, but I'm experiencing a timeout. The timeout is consistent with Edge and supported by the source that @ricea referenced, but then again, my testing methods may still be invalidating the experiment. Can you confirm that Chrome is expected to tolerate more than 4 invalid bytes in this case? The other interesting detail (and the one that started this whole investigation) is that Firefox becomes more tolerant of invalid data following a successful HTTP 204 response. This behavior is specific to 204's--the 4-byte threshold stands following an HTTP 200 response (for instance). I haven't been able to pin down the exact threshold in these conditions because results become unstable somewhere around 132,200 invalid bytes. View on GitHub: https://github.com/w3c/web-platform-tests/pull/5227#issuecomment-294031601
Received on Thursday, 13 April 2017 21:53:42 UTC