ServletResponseHttpHeaders ignores content type in ServletResponse
#32339
Assignees
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Milestone
Comments
sdeleuze
added
in: web
sdeleuze
changed the title
ServletResponseHttpHeaders ignores content type in ServletResponse
sdeleuze
added a commit
to sdeleuze/spring-framework
that referenced
this issue
Mar 4, 2024
This commit updates ServletServerHttpResponse.ServletResponseHttpHeaders in order to use ServletResponse#getContentType instead of ServletResponse#getHeader. It allows to have a consistent behavior between Tomcat (which set only the former) and Undertow/Jetty (which set both). See spring-projectsgh-32339
sdeleuze
added a commit
to sdeleuze/spring-framework
that referenced
this issue
Mar 4, 2024
This commit avoid calling HttpHeaders#getContentType multiple times in ServletServerHttpResponse#writeHeaders. Closes spring-projectsgh-32339
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Servlet API doesn't say that
Content-Typehas to be available inServletResponse.getHeader()and Tomcat actually takes explicit steps to ensure it is not stored as a header (despite being sent as a header to the remote client). So a lot of busywork goes on in Spring if the content type has been set explicitly but is coming back fromServletResponseHttpHeadersas null. Undertow (in contrast) internally chooses to store the content type as a header, so the two servers behave differently and Undertow is faster if the content type is explicitly set.The text was updated successfully, but these errors were encountered: