On 12/05/2026 14:40, Mark Thomas wrote:
On 12/05/2026 14:15, Rémy Maucherat wrote:
On Tue, May 12, 2026 at 1:46 PM Mark Thomas <[email protected]> wrote:
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.
We (kind of) allow this in a way: the connector has a secure flag
where it can be configured to say it is supposed to be secure. That is
why you have to configure both sslenabled and secure on the connector
when actually enabling a secure setup.
True. Although those only apply to HTTP and can only be used to force
http to be treated as https.
RemoteIpValve is arguably a better, more generic solution.
You got me thinking about maybe removing those settings from the Connector.
It has been a couple of weeks without any further comment. With the June
release window approaching now would be the time to make a case
adjusting this behaviour. Options include:
- do nothing (keep the new behaviour)
- revert the change
- make the change optional (with a configuration option - TBD)
- remove the secure and scheme settings entirely (and use RemoteIpValve)
- something else
I don't think I have strong views on any particular option. Do nothing
is my default option but only because I can;t see a strong argument for
on option over any of the others.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
