First reported against Eclipse Jetty at ...
- https://github.com/jetty/jetty.project/issues/12808
The stacktrace looks like this ...
java.lang.NumberFormatException: Cannot parse null string
at java.base/java.lang.Long.parseLong(Unknown Source)
at java.base/java.lang.Long.parseLong(Unknown Source)
at org.springframework.web.util.ContentCachingResponseWrapper.setHeader(ContentCachingResponseWrapper.java:167)
at org.eclipse.jetty.ee10.servlet.ServletCoreResponse$HttpServletResponseHttpFields.remove(ServletCoreResponse.java:389)
at org.eclipse.jetty.ee10.servlet.ServletCoreResponse$HttpServletResponseHttpFields.remove(ServletCoreResponse.java:397)
at org.eclipse.jetty.server.ResourceService.putHeaders(ResourceService.java:755)
at org.eclipse.jetty.server.ResourceService.sendData(ResourceService.java:669)
at org.eclipse.jetty.server.ResourceService.doGet(ResourceService.java:206)
at org.eclipse.jetty.ee10.servlet.ResourceServlet.doGet(ResourceServlet.java:530)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
What is happening is that the HttpServletResponse.setHeader("Content-Length", null) method is being called.
The ContentCachingResponseWrapper.setHeader(String, String) sees the Content-Length header and then blindly tries parse the value.
https://github.com/spring-projects/spring-framework/blob/b932df6ad25ee570909c3c2c1ed1a60bd49bbb48/spring-web/src/main/java/org/springframework/web/util/ContentCachingResponseWrapper.java#L161-L168
The servlet spec has always treated a null in the value parameter for setHeader as a remove of that header.
- https://github.com/jakartaee/servlet/issues/159
At a minimum, this code should be changed to pass-through any null value and do no further processing of the header. But I suspect you'll want to null out your tracking of the content-length header as well.