Report: Inconsistency in HTTP 204 response body parsing (#5227)

When a 204 response specifies as `Content-Length` header, different browsers exhibit different behaviors on different platforms. Although [the HTTP specification explicitly disallows this situation](https://tools.ietf.org/html/rfc7230#section-3.3.2), @annevk suggested that this might be behavior that should be accounted for in relevant W3C/WhatWG specifications.

I've opened this pull request to demonstrate the inconsistency. Please note that although the demo takes the form of a WPT test, it is *not* suitable for a number of reasons.

After checking out this branch, navigate to http://localhost:8000/http-demo/index.html . The tests perform the following actions:

1. Browser: perform a GET request for `demo.py?seq=1` by injecting a `<script>`
   tag into the document
2. Server: respond with `HTTP/1.1 204 No Content`, specifying a non-zero value
   for the `Content-Length` header, but omitting a body
3. Browser: in the `onload` event handler for the script created in step 1,
   perform a second GET request for `demo.py?seq=2` (again, by injecting a
   `<script>` tag into the document)
4. Server: write between zero and six bytes to the response stream that do
   *not* conform to HTTP
5. Server: respond with `HTTP/1.1 200 OK`, specifying a non-zero
   `Content-Length` and a complete body.

There are six sub-tests here: the first writes 0 non-HTTP (or "garbage") bytes in step 4; the following sub-tests write successively more bytes.

Results:

Browser               | Platform   | Behavior for request 1 | Behavior for request 2 (no "garbage)" | Behavior for request 2 (1-4 "garbage" bytes) | Behavior for request 2 (5 "garbage" bytes)
----------------------|------------|------------------------|---------------------------------------|----------------------------------------------|-------------------------------------------
Chromium 56           | GNU/Linux  | resolves successfully  | resolves successfully                 | resolves successfully                        | does not resolve
Chrome 59             | GNU/Linux  | resolves successfully  | resolves successfully                 | resolves successfully                        | reports network error `net::ERR_INVALID_HTTP_RESPONSE`
Chrome 57             | Windows 10 | resolves successfully  | resolves successfully                 | resolves with HTTP 502 error                 | resolves with HTTP 502 error
Firefox 52            | GNU/Linux  | resolves successfully  | resolves successfully                 | resolves successfully                        | resolves successfully
Firefox 52            | Windows 10 | resolves successfully  | resolves successfully                 | resolves with HTTP 502 error                 | resolves with HTTP 502 error
Safari (all versions) | all        | does not resolve       | n/a                                   | n/a                                          | n/a
Edge 13 & 14          | Windows 10 | does not resolve       | n/a                                   | n/a                                          | n/a

In all cases, the WPT server instance was running on a GNU/Linux system. Results for the GNU/Linux platform were collected using locally-running browsers. Results for Non-GNU/Linux platforms were collected using browsers running remotely (as provided by the BrowserStack service). It seems possible that this discrepancy contributed to the variation reported above.

*Note on determinism* These behaviors are only observable when requests 1 and 2 share the same connection. As far as I know, the user agent is free to distribute requests across connections in any manner. While the demonstration seems fairly reliable, I don't think it is technically stable.

View on GitHub: https://github.com/w3c/web-platform-tests/pull/5227

Received on Monday, 27 March 2017 15:00:18 UTC