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. Remy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
