Caused by: io.netty.handler.codec.http2.Http2Exception$HeaderListSizeException: Header size exceeded max allowed size (8192) #4284
Comments
|
Created netty/netty#7825 |
JLofgren
added a commit
to JLofgren/netty
that referenced
this issue
Apr 6, 2018
Motivation: When connecting to an HTTP/2 server that did not set any value for the SETTINGS_MAX_HEADER_LIST_SIZE in the settings frame, the netty client was imposing an arbitrary maximum header list size of 8kB. There should be no need for the client to enforce such a limit if the server has not specified any limit. This caused an issue for a grpc-java client that needed to send a large header to a server via an Envoy proxy server. The error condition is demonstrated here: https://github.com/JLofgren/demo-grpc-java-bug-4284 Fixes grpc-java issue netty#4284 - grpc/grpc-java#4284 and netty issue netty#7825 - netty#7825 Modifications: In HpackEncoder use MAX_HEADER_LIST_SIZE as default maxHeader list size. Result: HpackEncoder will only enforce a max header list size if the server has specified a limit in its settings frame.
Scottmitch
pushed a commit
to netty/netty
that referenced
this issue
Apr 16, 2018
Motivation: When connecting to an HTTP/2 server that did not set any value for the SETTINGS_MAX_HEADER_LIST_SIZE in the settings frame, the netty client was imposing an arbitrary maximum header list size of 8kB. There should be no need for the client to enforce such a limit if the server has not specified any limit. This caused an issue for a grpc-java client that needed to send a large header to a server via an Envoy proxy server. The error condition is demonstrated here: https://github.com/JLofgren/demo-grpc-java-bug-4284 Fixes grpc-java issue #4284 - grpc/grpc-java#4284 and netty issue #7825 - #7825 Modifications: In HpackEncoder use MAX_HEADER_LIST_SIZE as default maxHeader list size. Result: HpackEncoder will only enforce a max header list size if the server has specified a limit in its settings frame.
|
@ejona86 Does anything need to be done to make sure the netty fix will make it into the next java-grpc release? |
|
No, but it may not make the next release. It will make a "soon" gRPC release. Sometimes unrelated problems in the Netty release will prevent us from upgrading. Something would only need to be done if we were wanting to backport a fix/workaround. |
|
1.13.x upgraded Netty. This should be fixed. |
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
What version of gRPC are you using?
1.10.0
What did you expect to see?
This error occurs when a Java client attempts to send a header larger than 8192 bytes when connected to a server that did not explicitly specify a SETTINGS_MAX_HEADER_LIST_SIZE in its settings frame. (Note this cannot be replicated using a grpc-java server because netty always specifies a SETTINGS_MAX_HEADER_LIST_SIZE.)
The expected result is no error - the client should send the large header to the server.
The HTTP/2 spec Settings section says:
of the sending peer, which are used by the receiving peer.
These statements indicate that if the server does not specify any SETTINGS_MAX_HEADER_LIST_SIZE, then the client should place no limit on the sending header size. However, netty is enforcing a default max header size on both sent and received headers. And to boot, there does not seem to be any way to specify or disable the client sender header limit through the grpc-java API. NettyChannelBuilder has the maxHeaderListSize method, but this only specifies the SETTINGS_MAX_HEADER_LIST_SIZE for the receive path.
I think the proper fix would be for netty to not enforce any limit on client sent header size if the server has not specified a SETTINGS_MAX_HEADER_LIST_SIZE.
I am looking for a long-term fix for this issue and short-term workaround if anyone has an idea. Thanks!
The text was updated successfully, but these errors were encountered: