Re: 10.1.25 -> 10.1.33 - no more content-* headers in HEAD responses
On Wed, Nov 20, 2024 at 1:26 AM Pawel Veselov 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 > Date: Thu Jan 19 20:40:10 2023 + > 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 Date: Thu Jan 19 20:40:10 2023 + 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
Re: Shutting Down Tomcat (9.0.97) Service Throws System Error 1067
> On Nov 19, 2024, at 08:16, Kostyantyn Krakovych
> wrote:
>
> Hi Team,
>
> Could you please suggest or advice regarding the following?
>
> 1. We use Tomcat 9.0.87 as a windows service. It works fine with our
> application.
> 2. To fix security vulnerabilities we are upgrading Tomcat to version 9.0.97.
> 3. The upgraded service works fine except when shutting down/stopping it.
> When we stop the service via either console or Services app, we get system
> error 1067 (please check the Appendix A).
> 4. Event Viewer does not contain too many details about the issue (please
> check the Appendix B).
> 5. Nothing in logs though we redirect Tomcat logs to logs of our application.
> 6. We checked a set of versions, and it looks like the issue started to
> appear since Tomcat version 9.0.90.
>
> Any suggestions or advice how to find a cause of the issue after the upgrade
> is welcome.
Need a bit more information here. Is Tomcat behind a front-end such as httpd or
IIS? Are you using tcnative-1.dll? Is there any native code (other than the
JVM) deployed with the Tomcat application? Was a JVM dump file produced when
the process terminated unexpectedly? (Sorry, I don’t know where to look for
that on Windows.)
Can you post your connector configuration(s) - masking out any sensitive
information (eg, passwords)?
- Chuck
> Appendix A - Output in console when stooping the service
>
>> net stop
> The service is stopping.
> A system error has occurred.
> System error 1067 has occurred.
> The process terminated unexpectedly.
> The service was stopped successfully.
>
> Appendix B - Event Viewer details about the issue
>
> http://schemas.microsoft.com/win/2004/08/events/event";>
> -
> Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service
> Control Manager" />
> 7034
> 0
> 2
> 0
> 0
> 0x8080
>
> 1577729
>
>
> System
>
>
>
> -
>
> 140
>
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
10.1.25 -> 10.1.33 - no more content-* headers in HEAD responses
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 Date: Thu Jan 19 20:40:10 2023 + Update the default HEAD response to exclude payload headers First explicitly allowed in RFC 7231 and also in the current RFC 9110 (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
Shutting Down Tomcat (9.0.97) Service Throws System Error 1067
Hi Team, Could you please suggest or advice regarding the following? 1. We use Tomcat 9.0.87 as a windows service. It works fine with our application. 2. To fix security vulnerabilities we are upgrading Tomcat to version 9.0.97. 3. The upgraded service works fine except when shutting down/stopping it. When we stop the service via either console or Services app, we get system error 1067 (please check the Appendix A). 4. Event Viewer does not contain too many details about the issue (please check the Appendix B). 5. Nothing in logs though we redirect Tomcat logs to logs of our application. 6. We checked a set of versions, and it looks like the issue started to appear since Tomcat version 9.0.90. Any suggestions or advice how to find a cause of the issue after the upgrade is welcome. Appendix A - Output in console when stooping the service > net stop The service is stopping. A system error has occurred. System error 1067 has occurred. The process terminated unexpectedly. The service was stopped successfully. Appendix B - Event Viewer details about the issue http://schemas.microsoft.com/win/2004/08/events/event";> - 7034 0 2 0 0 0x8080 1577729 System - 140 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
