Reject malformed HTTP/2 responses that contain an invalid Content-Length header
Categories
(Core :: Networking: HTTP, defect, P2)
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 acontent-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-zerocontent-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.
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
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.
Description
•