New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
h2: Currently not honoring request limits #3709
Comments
Regarding http_req_size parameter, currently it is not taken into account when using h2, instead the checked parameter is h2_max_frame_size + 9 (h2 header size), which defaults to 16k (the minimum) |
We can't predict the length of headers until we decode them. They may be indexed in the session's HPACK dynamic table or compressed using a Huffman tree. I already checked left and right when I registered this issue that our HPACK decoder doesn't panic when it runs out of workspace. Ideally, we should successfully decode an HPACK block even when the number of headers, headers lengths or the overall request size go over the configured limits. If we fail to decode an HPACK block we have to fail the entire h2 session, and what we should strive for is the failure of the offending stream and nothing else. How should this stream fail? I did not research it last year, but I suspect it should simply be refused. RFC 7540 hopefully has an answer. |
The following test case passes, it should fail. Attempting the same request with HTTP/1 definitely fails. I'm not sure how the correct test case should look like, my assumption is that stream 1 should be reset and the connection preserved.
The text was updated successfully, but these errors were encountered: