Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)

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.

Mark