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

On 27/05/2026 20:40, Christopher Schultz wrote:
> 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.

Now opened as a bug under 
https://bz.apache.org/bugzilla/show_bug.cgi?id=70091

I suggest we continue the conversation there.

Mark