We try to block protocol/transport-specific headers for incoming requests from the set of headers that we propagate to backends. It turns out that this list was incomplete.
In particular, we would propagate a "Connection: keep-alive" header which (at least with a Go backend using H2C) causes the connection to behave incorrectly and the RPC to timeout. That was the culprit in the bug that we observed.
I also noticed the "Accept" header was being propagated (since we were only blocking headers that start with "Accept-"). In addition to blocking "Connection", I also added other headers to the block list -- ones that the RFC on HTTP/2 says should not be propagated (we already blocked most of them, but "Connection", "Proxy-Connection", and "Upgrade" weren't in our list). And I also added "Http2-Settings" to the block list as well as gRPC-protocol-specific headers (we already blocked Connect-protocol-specific headers, so this is just fleshing it out further).
We try to block protocol/transport-specific headers for incoming requests from the set of headers that we propagate to backends. It turns out that this list was incomplete.
In particular, we would propagate a "Connection: keep-alive" header which (at least with a Go backend using H2C) causes the connection to behave incorrectly and the RPC to timeout. That was the culprit in the bug that we observed.
I also noticed the "Accept" header was being propagated (since we were only blocking headers that start with "Accept-"). In addition to blocking "Connection", I also added other headers to the block list -- ones that the RFC on HTTP/2 says should not be propagated (we already blocked most of them, but "Connection", "Proxy-Connection", and "Upgrade" weren't in our list). And I also added "Http2-Settings" to the block list as well as gRPC-protocol-specific headers (we already blocked Connect-protocol-specific headers, so this is just fleshing it out further).
Fixes TCN-1704