HEAD response has "Content-Length: 0" for @RestController @GetMapping methods [SPR-15261]

[spring-projects-issues]

David Goblirsch opened SPR-15261 and commented

In response to HEAD, now handled by Spring for @GetMapping methods as of 4.3+, the HTTP spec says that it "should" include the same headers that GET would include, except that four header parameters are considered "optional". Content-Length is one of these optional headers for HEAD requests. BUT when it is included, it is supposed to have the same value as it would have been for GET, i.e., the length of the response body. My @RestController @GetMapping methods return the correct non-zero value for GET requests but are setting Content-Length: 0 for HEAD requests.

This is using Spring 4.3.6 on both JBoss 6.1 (yes, very old) and WildFly 10.1.

---

Affects: 4.3.6

Reference URL: http://stackoverflow.com/questions/27868314/avoiding-content-length-in-head-response

Issue Links:

• HTTP Response should not contain both Transfer-Encoding and Content-Length headers [SPR-15212] #19776 HTTP Response should not contain both Transfer-Encoding and Content-Length headers

Referenced from: commits b732251, 45b27a8

[spring-projects-issues]

David Goblirsch commented

I forgot to mention that I am using the "ShallowEtagHeaderFilter" to automatically get ETag and Content-Length headers in my responses.
For this purpose, I override "getServletFilters()" in my AbstractAnnotationConfigDispatcherServletInitializer, but I only create the ShallowEtagHeaderFilter object with the default, no-arg constructor and no additional configuration, so perhaps I have missed something.

[spring-projects-issues]

David Goblirsch commented

Indeed, when I remove the use of the ShallowEtagHeaderFilter I no longer get an ETag header (nor a Content-Length for GET) but I now get
the correct Content-Length value in response to HEAD. I do not get the Content-Length for GET, but for GET the Transfer Encoding is chunked.

[spring-projects-issues]

Brian Clozel commented

HEAD support in ShallowETagHeaderFilter was introduced in #17721, but I'm wondering if we should really execute the filter for those cases.

Responses to HEAD request should have similar headers to GET requests, with payload related headers possibly ignored. The filter writes the Content-Length and ETag headers using the actual response body and since in that case the response body is empty, I believe the filter should ignore completely HEAD requests.

What do you think David Goblirsch?

[spring-projects-issues]

Juergen Hoeller commented

Indeed, it looks like we should completely ignore HEAD requests in ShallowEtagHeaderFilter then...

[spring-projects-issues]

David Goblirsch commented

That seems ok to me; without the ShallowEtagHeaderFilter, the HEAD response is what I expected.

[spring-projects-issues]

David Goblirsch commented

I just upgraded to Spring 4.3.7. Using ShallowEtagHeaderFilter, I no longer get an ETag in response to a HEAD, only to GET. But the Content-Length is still zero for HEAD instead of the size that GET would have returned.

If I do not register the ShallowEtagFilter, I get the non-zero Content-Length in response to HEAD, but, of course, I do not get an ETag with a GET response.

So the "fix" stopped generating an ETag for HEAD but still says the Content-Length is zero.

[spring-projects-issues]

Juergen Hoeller commented

David Goblirsch, since 4.3.7 is already out, let's keep this JIRA issue here closed. Please create a follow-up issue against 4.3.7, about ShallowEtagHeaderFilter still sending Content-Length zero for HEAD requests. We'll sort it out for 4.3.8 then.