Open Bug 1830359 Opened 1 year ago Updated 14 days ago

Reject malformed HTTP/2 responses that contain an invalid Content-Length header

Categories

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

defect

Tracking

()

People

(Reporter: valentin, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

https://datatracker.ietf.org/doc/html/rfc9113#section-8.1.1-2

A request or response that includes message content can include a content-length header field. A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the content, unless the message is defined as having no content. For example, 204 or 304 responses contain no content, as does the response to a HEAD request. A response that is defined to have no content, as described in Section 6.4.1 of [HTTP], MAY have a non-zero content-length header field, even though no content is included in DATA frames.

For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream. Clients MUST NOT accept a malformed response.

We should make sure to include some WPT tests for this, and preferably some telemetry to see how often this happens.

Whiteboard: [necko-triaged] → [necko-triaged][necko-priority-queue]
See Also: → 1455614
Whiteboard: [necko-triaged][necko-priority-queue] → [necko-triaged]

Bug 1891321 is loosely related. Content-Length is probably correct about the object being fetched, but it does not match the size of the object that the user is deceived into believing they are fetching. In any case, it’s important for Content-Length to be accurate and to reflect what the user thinks they are fetching.

You need to log in before you can comment on or make changes to this bug.