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

On 03/07/2026 03:20, Christopher Schultz wrote:
> Thomas,
> 
> On 5/29/26 6:16 AM, Thomas Meyer wrote:
>>
>> Zitat von Christopher Schultz <[email protected]>:
>>
>>> Mark,
>>>
>>> On 5/26/26 1:34 PM, Mark Thomas wrote:
>>>> 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.
>>>
>>> +1 for "no additional changes".
>>>
>>> I think RemoteIPValve is the correct maneuver, here.
>>
>> Hi,
>>
>> we tried to use RemoteIPValve but it looks like this Valve is running 
>> way after the check done in https://github.com/apache/tomcat/blob/ 
>> main/ java/org/apache/coyote/http2/Stream.java
>> any suggestions how to proceed?
> 
> Sorry, just getting back to this.
> 
> Bumping to get this back in front of Mark and Rémy who understand the 
> http/2 pipeline way better than I do.

https://bz.apache.org/bugzilla/show_bug.cgi?id=70091

It was addressed in the June releases.

Mark