Re: Connection header override
Mark,
On 9/28/20 03:48, Mark Thomas wrote:
> On 28/09/2020 08:33, Mark Thomas wrote:
>> On 27/09/2020 00:07, Pawel Veselov wrote:
>>> Hello!
>>>
>>> Tomcat 9.0.x
>>>
>>> I'd like to force connection closure on some endpoints.
>>
>> Why? Generally, this is something that should not be an application concern.
>>
>>> I'm trying this on a simple JSP page.
>>> If I call response.setHeader("Connection","close"), I see that the
>>> response has "Connection: close, keep-alive".
>>> I assume Tomcat inserts the keep-alive part. It looks like the browsers
>>> still close the connection based on this, but I was wondering if it's
>>> possible to have Tomcat honor the header value set by the application.
>>
>> The most recent discussion on this topic was whether or not Tomcat
>> should block any attempt by an application to manipulate the Connection
>> header. The consensus was leaning towards implementing a block but
>> no-one has implemented it yet.
>>
>> See https://github.com/apache/tomcat/pull/277
>>
>> I did wonder if this was a regression introduced by some clean-up in the
>> handling of the Connection header a little while ago but it appears not.
>> Note that Tomcat will only add this header for HTTP/1.0 requests.
>> Separately, you may also see a "Keep-Alive" header for HTTP/1.1 requests.
>
> Testing shows that isn't right - I was mis-reading the code. You will
> see this with HTTP/1.1 requests where the client explicitly sends a
> "Connection: keep-alive header".
>
> I'm currently working on expanding the unit tests to cover this
> (although I'd still like to know why the app needs to close the connection).
One reason may be to "punish" a client for misbehaving in some way (e.g.
lots of failed logins, etc.). It's not much of a punishment, but forcing
a fresh TCP/IP and TLS handshake will slow down a brute-force script a bit.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection header override
On 28/09/2020 08:33, Mark Thomas wrote:
> On 27/09/2020 00:07, Pawel Veselov wrote:
>> Hello!
>>
>> Tomcat 9.0.x
>>
>> I'd like to force connection closure on some endpoints.
>
> Why? Generally, this is something that should not be an application concern.
>
>> I'm trying this on a simple JSP page.
>> If I call response.setHeader("Connection","close"), I see that the
>> response has "Connection: close, keep-alive".
>> I assume Tomcat inserts the keep-alive part. It looks like the browsers
>> still close the connection based on this, but I was wondering if it's
>> possible to have Tomcat honor the header value set by the application.
>
> The most recent discussion on this topic was whether or not Tomcat
> should block any attempt by an application to manipulate the Connection
> header. The consensus was leaning towards implementing a block but
> no-one has implemented it yet.
>
> See https://github.com/apache/tomcat/pull/277
>
> I did wonder if this was a regression introduced by some clean-up in the
> handling of the Connection header a little while ago but it appears not.
> Note that Tomcat will only add this header for HTTP/1.0 requests.
> Separately, you may also see a "Keep-Alive" header for HTTP/1.1 requests.
Testing shows that isn't right - I was mis-reading the code. You will
see this with HTTP/1.1 requests where the client explicitly sends a
"Connection: keep-alive header".
I'm currently working on expanding the unit tests to cover this
(although I'd still like to know why the app needs to close the connection).
Mark
>
> I'm leaning towards a small fix that would prevent the keep-alive header
> being added in this case.
>
>> I was also wondering what does it mean - when multiple connection tokens
>> are specified for a connection header. Breezing through the RFCs I can't
>> find a clear statement on that except that multiple connection tokens are
>> allowed in the header...
>
> As per RFC 7230, section 6.3 if the close option is present it takes
> priority.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection header override
On 27/09/2020 00:07, Pawel Veselov wrote:
> Hello!
>
> Tomcat 9.0.x
>
> I'd like to force connection closure on some endpoints.
Why? Generally, this is something that should not be an application concern.
> I'm trying this on a simple JSP page.
> If I call response.setHeader("Connection","close"), I see that the
> response has "Connection: close, keep-alive".
> I assume Tomcat inserts the keep-alive part. It looks like the browsers
> still close the connection based on this, but I was wondering if it's
> possible to have Tomcat honor the header value set by the application.
The most recent discussion on this topic was whether or not Tomcat
should block any attempt by an application to manipulate the Connection
header. The consensus was leaning towards implementing a block but
no-one has implemented it yet.
See https://github.com/apache/tomcat/pull/277
I did wonder if this was a regression introduced by some clean-up in the
handling of the Connection header a little while ago but it appears not.
Note that Tomcat will only add this header for HTTP/1.0 requests.
Separately, you may also see a "Keep-Alive" header for HTTP/1.1 requests.
I'm leaning towards a small fix that would prevent the keep-alive header
being added in this case.
> I was also wondering what does it mean - when multiple connection tokens
> are specified for a connection header. Breezing through the RFCs I can't
> find a clear statement on that except that multiple connection tokens are
> allowed in the header...
As per RFC 7230, section 6.3 if the close option is present it takes
priority.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection header override
Pawel,
On 9/26/20 19:07, Pawel Veselov wrote:
> Hello!
>
> Tomcat 9.0.x
>
> I'd like to force connection closure on some endpoints.
> I'm trying this on a simple JSP page.
> If I call response.setHeader("Connection","close"), I see that the
> response has "Connection: close, keep-alive".
> I assume Tomcat inserts the keep-alive part. It looks like the browsers
> still close the connection based on this, but I was wondering if it's
> possible to have Tomcat honor the header value set by the application.
Are you sure your application isn't issuing both headers? Or maybe a
proxy in between Tomcat and the browser?
> I was also wondering what does it mean - when multiple connection tokens
> are specified for a connection header. Breezing through the RFCs I can't
> find a clear statement on that except that multiple connection tokens are
> allowed in the header...
While it doesn't really make any sense to have the header value be
"close, keep-alive", it's a valid header value. The Connection header
requires at least one value, but can accept any number of them.
A reasonable client should expect that any "close" present means that
the connection should be closed after the response has completed.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Connection header override
Hello!
Tomcat 9.0.x
I'd like to force connection closure on some endpoints.
I'm trying this on a simple JSP page.
If I call response.setHeader("Connection","close"), I see that the
response has "Connection: close, keep-alive".
I assume Tomcat inserts the keep-alive part. It looks like the browsers
still close the connection based on this, but I was wondering if it's
possible to have Tomcat honor the header value set by the application.
I was also wondering what does it mean - when multiple connection tokens
are specified for a connection header. Breezing through the RFCs I can't
find a clear statement on that except that multiple connection tokens are
allowed in the header...
Thank you!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
