elixir-mint / mint / 65fe496e7fd9ea184ea38d0c87a8c7a35f4a0186

91%

push

github

Validate HTTP/2 DATA, padding, SETTINGS and extension frames (#512)

* Validate HTTP/2 DATA frames against flow control padding and message order

The flow-control accounting for a padded DATA frame counted the data
and the padding but not the Pad Length byte, while RFC 9113 6.1 says the
whole payload is flow controlled. The server's view of the receive
window drifted by one byte per padded frame, and once the drift passed
the WINDOW_UPDATE threshold the server saw an empty window that the
client never refilled.

A DATA frame arriving before the response HEADERS frame was delivered
as a :data response with no preceding :status. RFC 9113 8.1 defines a
response as HEADERS followed by DATA, and 8.1.1 makes a malformed
response a stream error, so the stream is now reset with PROTOCOL_ERROR
and the caller receives an error response.

* Validate HTTP/2 frame padding and SETTINGS before using them

A DATA, HEADERS or PUSH_PROMISE frame with the PADDED flag and an empty
payload has no Pad Length field and is a FRAME_SIZE_ERROR (RFC 9113 6.1),
a SETTINGS frame with the ACK flag and a payload is a FRAME_SIZE_ERROR
(RFC 9113 6.5), and SETTINGS_ENABLE_PUSH is only valid as 0 or 1 and must
not be set to 1 by a server (RFC 9113 6.5.2). All three used to be
accepted.

* Accept HTTP/2 PRIORITY frames on idle streams and reject extension frames in header blocks

PRIORITY frames on a client stream ID the client hadn't opened yet were
treated as a connection error, but RFC 9113 5.1 allows PRIORITY on idle
streams. They are now accepted.

Extension frames received in the middle of a header block were ignored
instead of being treated as the PROTOCOL_ERROR RFC 9113 5.5 requires.

38 of 39 new or added lines in 2 files covered. (97.44%)

1690 of 1887 relevant lines covered (89.56%)

659.45 hits per line