I've been debugging an issue while using the Jetty ProxyServlet to proxy all requests to a backend server which uses the mvc:resources namespace element. I finally tracked the issue down to Jetty's ProxyServlet hanging while waiting for content from the backend server. Originally I thought this was a Jetty issue, but as I look at the HTTP headers, I think it is an issue with ResourceHttpRequestHandler.
ResourceHttpRequestHandler, at line 124 always sets the HTTP headers of Content-Length and Content-Type. Immediately after this call, at line 125, the response is returned if it is found that the resource hasn't changed and a 304 can be returned. What this means is that a "304 Not Modified" status is returned but the Content-Length header is set.
I've found conflicting reports as to who is in the wrong here, but RFC 2616 says,
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
So, in either case (strong or weak validators), it seems like the ResourceHttpRequestHandler should not be setting a Content-Length header because clients could hang waiting for the content.
So is this a bug in Spring? Is there any workaround besides sub-classing the handler or disabling the cache?