1690481 - HTTP/1: return a network error for responses with no LF after headers

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Anne (:annevk)]

We have rather scary behavior currently when this happens. In particular, when I modify
fetch/h1-parsing/resources/status-code.py and remove the final newline and then run fetch/h1-parsing/status-code.window.js (as fetch/h1-parsing/status-code.window.html) it returns status codes such as 54976 (where 1 is expected) and if you refresh it will list a different status code there. That suggests that something is rather broken.

Tests: https://github.com/web-platform-tests/wpt/pull/27456. (These don't exhibit the above behavior because they expect a network error, as Safari already does. Chrome does not however, but I suspect they would want to align on at least requiring a single newline.)

Context: https://github.com/whatwg/fetch/issues/472.

Comment 1

[Kershaw Chang [:kershaw]]

Attachment: Bug 1690481 - Make the fetch request fail when response is not available

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5545af58b161
Make the fetch request fail when response is not available r=baku

Comment 3

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/5545af58b161

Comment 4

[Anne (:annevk)]

Hey Kershaw, is there a follow-up bug for the issue found during review? While the test only found this for fetch(), it seems likely that other code also assumes status is available once the network layer returns a response.

Comment 5

[Kershaw Chang [:kershaw]]

(In reply to Anne (:annevk) from comment #4)

Hey Kershaw, is there a follow-up bug for the issue found during review? While the test only found this for fetch(), it seems likely that other code also assumes status is available once the network layer returns a response.

Sorry that I forgot to mention I already filed bug 1694361 for this.