You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2026/05/05 14:49:31 UTC
[ANN] Apache Tomcat 11.0.22 Available
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.22.
Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta
WebSocket, Jakarta Authentication and Jakarta Annotations specifications.
The notable changes compared to 11.0.21 include:
- Enhance version.sh and version.bat to display APR, Tomcat Native, and
OpenSSL version information.
- Free private keys, keys and certificates after use in FFM based
connector configuration.
- Various HTTP/2 validation improvements and a broader change to use
stream resets rather than connection closures where appropriate.
Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html
Downloads:
http://tomcat.apache.org/download-11.cgi
Migration guides from Apache Tomcat 9.0.x and 10.1.x:
http://tomcat.apache.org/migration.html
Enjoy!
- The Apache Tomcat team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Apache Tomcat x.x.x Available?
Posted by Chuck Caldarale <n8...@gmail.com>.
> On May 12, 2026, at 07:58:17, Mark Foley <mf...@novatec-inc.com> wrote:
>
> Thanks, that partially answers the question.
>
> But, why are we maintaining different versions of Servlet API's? A couple of
> years ago I went to some trouble converting from 9.x to 10.x because I thought I
> was "upgrading".
You might want to read this:
https://tomcat.apache.org/whichversion.html
> Could I have just stuck with 9.x?
You could have, for a while. Never hurts to keep up.
> Is 10.x -> 11.x something I should do (upgrade) or just stick with 10.x?
I would upgrade, but your circumstances could easily be different. Read this to help decide:
https://tomcat.apache.org/migration-11.0.html
- Chuck
> THX --Mark
>
> On Tue, 12 May 2026 21:28:33 +0900 David Wall <da...@yozons.com> wrote:
>
>> Different versions of Java and Servlet APIs and Java EE architectures.
>>
>> On 5/12/26 9:08 PM, Mark Foley wrote:
>>> Recently I've received emails from this list with the following subjects:
>>>
>>> Apache Tomcat 9.0.117 available
>>>
>>> Apache Tomcat 10.1.54 Available
>>>
>>> Apache Tomcat 11.0.21 Available
>>>
>>> I'm mildly confused. Most packages I use have a current, maintained release, period. Is Apache Tomcat running 3 parallel releases? It seems 9, 10 and 11 are all getting periodic updates.
>>>
>>> If Apache Tomcat is maintaining 3 parallel releases, why?
>>>
>>> THX --Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Apache Tomcat x.x.x Available?
Posted by Mark Foley <mf...@novatec-inc.com>.
Thanks, that partially answers the question.
But, why are we maintaining different versions of Servlet API's? A couple of
years ago I went to some trouble converting from 9.x to 10.x because I thought I
was "upgrading".
Could I have just stuck with 9.x?
Is 10.x -> 11.x something I should do (upgrade) or just stick with 10.x?
THX --Mark
On Tue, 12 May 2026 21:28:33 +0900 David Wall <da...@yozons.com> wrote:
> Different versions of Java and Servlet APIs and Java EE architectures.
>
> On 5/12/26 9:08 PM, Mark Foley wrote:
> > Recently I've received emails from this list with the following subjects:
> >
> > Apache Tomcat 9.0.117 available
> >
> > Apache Tomcat 10.1.54 Available
> >
> > Apache Tomcat 11.0.21 Available
> >
> > I'm mildly confused. Most packages I use have a current, maintained release, period. Is Apache Tomcat running 3 parallel releases? It seems 9, 10 and 11 are all getting periodic updates.
> >
> > If Apache Tomcat is maintaining 3 parallel releases, why?
> >
> > THX --Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Apache Tomcat x.x.x Available?
Posted by David Wall <da...@yozons.com>.
Different versions of Java and Servlet APIs and Java EE architectures.
On 5/12/26 9:08 PM, Mark Foley wrote:
> Recently I've received emails from this list with the following subjects:
>
> Apache Tomcat 9.0.117 available
>
> Apache Tomcat 10.1.54 Available
>
> Apache Tomcat 11.0.21 Available
>
> I'm mildly confused. Most packages I use have a current, maintained release, period. Is Apache Tomcat running 3 parallel releases? It seems 9, 10 and 11 are all getting periodic updates.
>
> If Apache Tomcat is maintaining 3 parallel releases, why?
>
> THX --Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Apache Tomcat x.x.x Available?
Posted by Mark Foley <mf...@novatec-inc.com>.
Recently I've received emails from this list with the following subjects:
Apache Tomcat 9.0.117 available
Apache Tomcat 10.1.54 Available
Apache Tomcat 11.0.21 Available
I'm mildly confused. Most packages I use have a current, maintained release, period. Is Apache Tomcat running 3 parallel releases? It seems 9, 10 and 11 are all getting periodic updates.
If Apache Tomcat is maintaining 3 parallel releases, why?
THX --Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Mark Thomas <ma...@apache.org>.
On 03/07/2026 03:20, Christopher Schultz wrote:
> Thomas,
>
> On 5/29/26 6:16 AM, Thomas Meyer wrote:
>>
>> Zitat von Christopher Schultz <ch...@christopherschultz.net>:
>>
>>> 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 <ma...@apache.org> wrote:
>>>>>>>
>>>>>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>>>>>
>>>>>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>>>>>
>>>>>>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Thomas,
On 5/29/26 6:16 AM, Thomas Meyer wrote:
>
> Zitat von Christopher Schultz <ch...@christopherschultz.net>:
>
>> 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 <ma...@apache.org> wrote:
>>>>>>
>>>>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>>>>
>>>>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>>>>
>>>>>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Thomas Meyer <th...@m3y3r.de>.
Zitat von Christopher Schultz <ch...@christopherschultz.net>:
> 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 <ma...@apache.org> wrote:
>>>>>
>>>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>>>
>>>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>>>
>>>>>> 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?
mfg
thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Mark Thomas <ma...@apache.org>.
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 <ma...@apache.org> wrote:
>>>>>
>>>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>>>
>>>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>>>
>>>>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <ma...@apache.org> wrote:
>>>>
>>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>>
>>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>>
>>>>> 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.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Mark Thomas <ma...@apache.org>.
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 <ma...@apache.org> wrote:
>>>
>>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>>
>>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>>
>>>> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Mark Thomas <ma...@apache.org>.
On 12/05/2026 14:15, Rémy Maucherat wrote:
> On Tue, May 12, 2026 at 1:46 PM Mark Thomas <ma...@apache.org> wrote:
>>
>> On 12/05/2026 09:36, Thomas Meyer wrote:
>>>
>>> Zitat von Mark Thomas <ma...@apache.org>:
>>>
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, May 12, 2026 at 1:46 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 12/05/2026 09:36, Thomas Meyer wrote:
> >
> > Zitat von Mark Thomas <ma...@apache.org>:
> >
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Mark Thomas <ma...@apache.org>.
On 12/05/2026 09:36, Thomas Meyer wrote:
>
> Zitat von Mark Thomas <ma...@apache.org>:
>
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
The scheme https s not consistent with the TLS enabled setting (Re: [ANN] Apache Tomcat 11.0.22 Available)
Posted by Thomas Meyer <th...@m3y3r.de>.
Zitat von Mark Thomas <ma...@apache.org>:
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?
We will revert to 11.0.21 for now.
Mfg
thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org