Closed Bug 1356614 Opened 7 years ago Closed 7 years ago

Response parsing inconsistent following a 204 response

Categories

(Developer Documentation Graveyard :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jugglinmike, Unassigned)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

Attached file lax-http.py
When parsing HTTP/1.1 responses, Firefox consistently tolerates anywhere
between 1 and 4 bytes of invalid data preceding the initial `HTTP` token.  If
there are 5 or more bytes of invalid data, Firefox generally ignores the
payload completely and continues to wait for a valid response.

However, if this event occurs on a TCP connection that previously delivered an
HTTP 204 ("No Content") response, then Firefox will tolerate a great deal more
invalid date. I haven't been able to determine the exact amount; it is well
over a kilobyte, but the behavior becomes unstable after that.

This seems unnecessarily lax and can lead to inconsistencies in behavior
between Firefox and other major browsers. See, for example, the following
discussion on a test for the Web Platform Tests project:

https://github.com/w3c/web-platform-tests/pull/5037

I have attached a demonstration Python script that starts a web server on port
9000. It may be run via the following command:

    python lax-http.py

And subsequently accessed via http://localhost:9000
Whiteboard: [necko-next]
Flags: needinfo?(mcmanus)
yes, its because servers often send bodies on responses defined not to have them (204/304). so we do it on purpose.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mcmanus)
Resolution: --- → WONTFIX
in general there are not normative requirements for the handling invalid behavior from the peer (in this case the invalid data before the HTTP).. so writing a test case around it seems rather unlikely to lead to a satisfying conclusion..
I don't think this should be closed without us documenting what we're doing as other browsers run into problems because of that. This is the reason we define error handling everywhere else in the web platform stack. It's not clear that networking should be an exception.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
It seems that
Component: Networking: HTTP → General
Product: Core → Developer Documentation
Whiteboard: [necko-next]
Keyword might work as well.
Keywords: dev-doc-needed
Anne: I'm happy to follow up with the documentation you requested, but I don't
know where it belongs. Can you point me in the right direction?
Flags: needinfo?(annevk)
I think Patrick would know that better than me. But he also appears to disagree with me on this and similar issues and we haven't really come to an understanding thus far. :/
Flags: needinfo?(annevk)
I think you're right about this ticket's classification as a "bug", but it's
currently filed as a request for documentation. That seems much less
controversial.

What do you say, Patrick? Do you know where I should be writing this
documentation?
Flags: needinfo?(mcmanus)
My 2ct here, a note on Browser Compatibility on MDN could be a good start:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
I don't really object to comment 9, but I'm not strongly in favor of it.. all those browsers are compatible with 204 as specified (afaik anyhow). What you are looking for is a chart on server incompatibility.
Flags: needinfo?(mcmanus)
Taking a cue from the documentation from `Data.parse` [1], I thought I would
add a new "Compatibility notes" section immediately following the "Browser
compatibility" section:

> # Compatibility notes
>
> - Although this status code is intended to describe a response with no body,
>   servers may erroneously include data following the headers. The protocol
>   allows user agents to vary in how they process such responses. This is
>   observable in persistent connections, where the invalid body may include a
>   distinct response to a subsequent request.
>
>   Apple Safari rejects any such data. Google Chrome and Microsoft Edge
>   discard up to four invalid bytes preceding a valid response. Firefox
>   tolerates in excess of a kilobyte of invalid data preceding a valid
>   response.

According to the relevant source code ([2] and [3]), it looks as though this
behavior is triggered following 205 and 304 responses as well.


Anne: does this look good to you? And do you think it should be copied for each
of the three pages, or perhaps only included in full for the 204 page, and only
referenced via hyperlink from the 205 and 304 pages?

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse
[2] https://dxr.mozilla.org/mozilla-central/rev/bd1b6a4e5d8e1184a89ae60a74fd86d3d4a9e95c/netwerk/protocol/http/nsHttpTransaction.cpp#1403
[3] https://dxr.mozilla.org/mozilla-central/rev/bd1b6a4e5d8e1184a89ae60a74fd86d3d4a9e95c/netwerk/protocol/http/nsHttpTransaction.cpp#1559
Flags: needinfo?(annevk)
That looks pretty good to me. I'd just add a reference from 205 and 304 I suppose. Maybe also add a pointer to the httpbisbis issue you created?
Flags: needinfo?(annevk)
You got it:

- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304

Thanks for your help, Anne!
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Thanks for documenting this difference!  Does anyone have an argument though for why Firefox's ~1Kb is better (or more web compatible) than Chrome and Edge's "up to 4 bytes"?  If it was actually meaningfully more web compatible then we might be willing to change Chrome to match Firefox.  Otherwise why not have Firefox change to match Chrome just to reduce the chance for developer pain / wasted time?  Whenever any web developer wastes THIS MUCH time (https://bocoup.com/blog/the-caper-of-the-flaky-test) on an interop difference, I can't help but feel like it's strong evidence that "just document the difference in behavior" is not the right outcome for the health of the web.

FWIW I think MikeT (Mozilla web compat) would agree that the reluctance to dictate behavior in the HTTP spec (https://github.com/httpwg/http11bis/issues/26) isn't very relevant here - interop is valuable even when not captured by specs.  Perhaps it would even be worth putting something into the compat spec (compat.spec.whatwg.org) if we can 3 engines to agree?
Sounds like this is documented now, so setting to dev-doc-complete. Please advise if I'm wrong; happy to help.
Tom, any thoughts here?
Flags: needinfo?(twisniewski)
Not being technically familiar with this quirk, I can only really offer that it would indeed be best to at least document any such atypical behavior we have and why we do it. Some telemetry numbers might also help us get others to adopt the quirk, if nothing else.
Flags: needinfo?(twisniewski)
You need to log in before you can comment on or make changes to this bug.