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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
