On Wed, Nov 20, 2024 at 1:26 AM Pawel Veselov <pawel.vese...@gmail.com> wrote: > > Hello. > > Upgrading Tomcat from 10.1.25 to 10.1.33 caused our sanity tests to > fail as the "content-length" header field is no longer present in the > HEAD responses. > > The application explicitly sets the content-length header on HEAD requests. > > The change is traced to this commit: > > commit 8e786a8eda > Author: Mark Thomas <ma...@apache.org> > Date: Thu Jan 19 20:40:10 2023 +0000 > Update the default HEAD response to exclude payload headers > First explicitly allowed in RFC 7231 and also in the current RFC 9110
After a bit more of digging around. The commit, as went into 10.1.x: commit b9198b0e35 Author: Mark Thomas <ma...@apache.org> Date: Thu Jan 19 20:40:10 2023 +0000 Update the default HEAD response to exclude payload headers First explicitly allowed in RFC 7231 and also in the current RFC 9110. Servlet 6.0 references RFC 7231 Fixes BZ https://bz.apache.org/bugzilla/show_bug.cgi?id=69379 I understand that #69379 complained about spurious content-length: 0, but I think the change that kills them completely is even a more serious regression. > (I compared the tags and see that this change shows up as being > between .25 and .33 despite the older commit date). > > I understand that RFC 9110 says that the application may omit headers > for which the values are determined while generating the content, but > for these endpoints the values are (a) static, and (b) explicitly set > by the servlet. But that also, at least to me, implies that if the > values are not generated, and are known, it's perfectly legal to > include them in the response. > > Unfortunately, our client implementation depends on these headers > values being present in HEAD responses. > > Is there a way to override this behavior? > If not, are there plans to make this behavior more customizable? > > We are trying to upgrade due to CVE-2024-52316. We don't use JASPIC, > and can suppress the vulnerability check, but this will hinder any > further upgrades. > > Thank you, > Pawel. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org