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

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.

-chris