On 12/05/2026 09:36, Thomas Meyer wrote:
Zitat von Mark Thomas <[email protected]>:
Hi,
- Various HTTP/2 validation improvements and a broader change to use
stream resets rather than connection closures where appropriate.
After upgrading our applications to tomcat 11.0.22 we see only
connection errors 503 for our setup.
We do run Tomcat behind istio/envoy proxy and tomcat uses h2c mode.
Istio Service mash handles TLS and Tomcat speaks clear text http2.
We see those error messages in our logs: "Connection [{0}], Stream
[{1}], The scheme [{2}] is not consistent with the TLS enabled setting
of [{3}]"
which seems to come from this change:
https://github.com/apache/tomcat/commit/96817a0
Bug or feature?
Hmm. The change was intentional. The motivation was a security review
that highlighted that clients could connect over h2c to a resource that
required TLS. We rejected that as a vulnerability since the attacker can
only harm their own privacy but we did opt to fix the behaviour to
protect users from client side error / misconfiguration.
I think the change is consistent with RFC 9113 but there is a reference
to RFC 9112 3.3 which in turn references a "trusted gateway" which is
the case you describe. However, Tomcat currently has no way to determine
(without additional configuration) if an HTTP/2 request is from a
trusted gateway or not.
Tomcat normally uses the RemoteIpValve in situations where the
application needs to see the protocol used by the client irrespective of
the protocol used between the proxy and Tomcat.
How practical is it to configure your proxy to use http for :scheme and
have it set the X-Forwarded-Proto header? You'd also need to configure
the RemoteIpValve Tomcat on Tomcat?
Another solution would be to use h2 rather than h2c between the proxy
and Tomcat.
On balance I'm leaning towards the new behaviour of requiring some
explicit configuration if proxying secure traffic over h2c. I'll note
that if you proxy over http you'll need similar configuration although
AJP (which only supports clear text) will allow this without further
configuration.
All that said, I am open to being convinced to either revert the new
behaviour or make it optional.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
