You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section).
AFAIU this should also apply to error responses, but when the Jetty embedded container
is used the requirement is not respected.
Starting from a vanilla Spring Boot app created from the Spring Initializer, a simple way
to check this is do an HEAD for a resource that does not exist.
One of our services relies on features in Jetty, so we cannot easily switch to the Tomcat container, and this HEAD behavior is causing problems to some clients.
Thanks!
The text was updated successfully, but these errors were encountered:
wilkinsona
changed the title
Spring boot with Jetty embedded sends body for HEAD requests that result in an error
Spring Boot with Jetty embedded sends body for HEAD requests that result in an error
Oct 1, 2020
wilkinsona
changed the title
Spring Boot with Jetty embedded sends body for HEAD requests that result in an error
When using embedded Jetty, an error response to a HEAD request has a body
Oct 1, 2020
Due to this Spring Boot issue:
spring-projects/spring-boot#23551
StoRM WebDAV was returning body for head requests that resulted in
error.
Until Spring Boot 2.2.11 is released here there's a workaround (that
basically incorporates the upstream code fix here).
Dear Spring Boot devs,
according to the HTTP RFC:
The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at
the end of the header section).
AFAIU this should also apply to error responses, but when the Jetty embedded container
is used the requirement is not respected.
Starting from a vanilla Spring Boot app created from the Spring Initializer, a simple way
to check this is do an HEAD for a resource that does not exist.
The result when the Tomcat container is used is:
The result when Jetty is used is:
The two apps are built using maven. The only difference in the pom.xml is the selection of the embedded container:
One of our services relies on features in Jetty, so we cannot easily switch to the Tomcat container, and this HEAD behavior is causing problems to some clients.
Thanks!
The text was updated successfully, but these errors were encountered: