You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Boris Petrov <bo...@profuzdigital.com> on 2019/09/12 14:19:30 UTC
Tomcat sets `Content-Length: 0` for 304 responses on HTTP/2
Hi,
I have two issues with the "default" Tomcat configuration (the only
thing I've changed from it is that I've added an `UpgradeProtocol`
directive and SSL certificates). Tomcat version is 9.0.24.
The first one is the one I've written in the subject - for all 304
responses Tomcat is adding a `Content-Length: 0` header. This happens
only on HTTP/2. Any suggestions how to debug this are appreciated.
The second issue is that Tomcat sets the same ETag header for a static
file that changes between updates of my WAR. That is, I have a file
called `git-revision.json` in which there is the build-date and the
revision-number of the application. This file changes with every new
release of our WAR. Note that the length of the file is always the same.
And Tomcat *ALWAYS* puts the same ETag header for it -
`W/"89-318204000000"` (89 is the file length, not sure about the rest).
Why is Tomcat not changing the ETag header? This breaks for clients
which have already loaded it and don't get the new version because 304
is returned.
Thanks in advance,
Boris Petrov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat sets `Content-Length: 0` for 304 responses on HTTP/2
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/2019 16:34, Boris Petrov wrote:
> Hi,
>
> Thanks for the response.
>
> About the first issue - I opened this issue for it:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63710
Fell free to re-open that issue and add the additional info.
> However I now see that I didn't specify that it was specifically on
> HTTP/2. Sorry about that.
>
> About the second issue - you're right, it is our fault, we've configured
> Gradle to put such a timestamp. Thanks for the support!
>
> Is the fix for issue 1 going to be in 9.0.25?
I don't see any reason why not at this point.
Mark
>
> Thanks again,
>
> Boris
>
> On 9/12/19 6:21 PM, Mark Thomas wrote:
>> On September 12, 2019 2:19:30 PM UTC, Boris Petrov <bo...@profuzdigital.com> wrote:
>>> Hi,
>>>
>>> I have two issues with the "default" Tomcat configuration (the only
>>> thing I've changed from it is that I've added an `UpgradeProtocol`
>>> directive and SSL certificates). Tomcat version is 9.0.24.
>>>
>>> The first one is the one I've written in the subject - for all 304
>>> responses Tomcat is adding a `Content-Length: 0` header. This happens
>>> only on HTTP/2. Any suggestions how to debug this are appreciated.
>> That looks like a Tomcat bug. The flow for HTTP/2 is different to HTTP/1.1 and it looks like we missed a check.
>>
>>> The second issue is that Tomcat sets the same ETag header for a static
>>> file that changes between updates of my WAR. That is, I have a file
>>> called `git-revision.json` in which there is the build-date and the
>>> revision-number of the application. This file changes with every new
>>> release of our WAR. Note that the length of the file is always the
>>> same.
>>> And Tomcat *ALWAYS* puts the same ETag header for it -
>>> `W/"89-318204000000"` (89 is the file length, not sure about the rest).
>> It is the last modified timestamp.
>>
>>> Why is Tomcat not changing the ETag header? This breaks for clients
>>> which have already loaded it and don't get the new version because 304
>>> is returned.
>> If the file contents changes the expectation is that the timestamp changes too.
>>
>> 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: Tomcat sets `Content-Length: 0` for 304 responses on HTTP/2
Posted by Boris Petrov <bo...@profuzdigital.com>.
Hi,
Thanks for the response.
About the first issue - I opened this issue for it:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63710
However I now see that I didn't specify that it was specifically on
HTTP/2. Sorry about that.
About the second issue - you're right, it is our fault, we've configured
Gradle to put such a timestamp. Thanks for the support!
Is the fix for issue 1 going to be in 9.0.25?
Thanks again,
Boris
On 9/12/19 6:21 PM, Mark Thomas wrote:
> On September 12, 2019 2:19:30 PM UTC, Boris Petrov <bo...@profuzdigital.com> wrote:
>> Hi,
>>
>> I have two issues with the "default" Tomcat configuration (the only
>> thing I've changed from it is that I've added an `UpgradeProtocol`
>> directive and SSL certificates). Tomcat version is 9.0.24.
>>
>> The first one is the one I've written in the subject - for all 304
>> responses Tomcat is adding a `Content-Length: 0` header. This happens
>> only on HTTP/2. Any suggestions how to debug this are appreciated.
> That looks like a Tomcat bug. The flow for HTTP/2 is different to HTTP/1.1 and it looks like we missed a check.
>
>> The second issue is that Tomcat sets the same ETag header for a static
>> file that changes between updates of my WAR. That is, I have a file
>> called `git-revision.json` in which there is the build-date and the
>> revision-number of the application. This file changes with every new
>> release of our WAR. Note that the length of the file is always the
>> same.
>> And Tomcat *ALWAYS* puts the same ETag header for it -
>> `W/"89-318204000000"` (89 is the file length, not sure about the rest).
> It is the last modified timestamp.
>
>> Why is Tomcat not changing the ETag header? This breaks for clients
>> which have already loaded it and don't get the new version because 304
>> is returned.
> If the file contents changes the expectation is that the timestamp changes too.
>
> 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
Re: Tomcat sets `Content-Length: 0` for 304 responses on HTTP/2
Posted by Mark Thomas <ma...@apache.org>.
On September 12, 2019 2:19:30 PM UTC, Boris Petrov <bo...@profuzdigital.com> wrote:
>Hi,
>
>I have two issues with the "default" Tomcat configuration (the only
>thing I've changed from it is that I've added an `UpgradeProtocol`
>directive and SSL certificates). Tomcat version is 9.0.24.
>
>The first one is the one I've written in the subject - for all 304
>responses Tomcat is adding a `Content-Length: 0` header. This happens
>only on HTTP/2. Any suggestions how to debug this are appreciated.
That looks like a Tomcat bug. The flow for HTTP/2 is different to HTTP/1.1 and it looks like we missed a check.
>The second issue is that Tomcat sets the same ETag header for a static
>file that changes between updates of my WAR. That is, I have a file
>called `git-revision.json` in which there is the build-date and the
>revision-number of the application. This file changes with every new
>release of our WAR. Note that the length of the file is always the
>same.
>And Tomcat *ALWAYS* puts the same ETag header for it -
>`W/"89-318204000000"` (89 is the file length, not sure about the rest).
It is the last modified timestamp.
>Why is Tomcat not changing the ETag header? This breaks for clients
>which have already loaded it and don't get the new version because 304
>is returned.
If the file contents changes the expectation is that the timestamp changes too.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org