I'm
trying to use the ProxyServlet to create a simple frontend SSL proxy and I'm
seeing it hang on 304 responses from my backend. After about 30 seconds the
proxy returns with a gateway timeout error for the request.
I
did discover that the backend is setting a Content-Length header for the 304
response so I'm assuming the problem is that the ProxyServlet is waiting for
the content, even though it will never be returned. I filed an issue against
Spring (the backend servlet) for setting the Content-Length header, but I'm not
convinced that it is all their fault. Based on my reading of RFC 2616, both
ends seem to behave incorrectly.
RFC
2616 section 10.3.5 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."
of
course, RFC 2616 section 4.4 says,
"Any
response message which "MUST NOT" include a message-body (such as the
1xx, 204, and 304 responses and any response to a HEAD request) is always
terminated by the first empty line after the header fields, regardless of the
entity-header fields present in the message."
So,
in either case (strong or weak validators), it seems like the backend servlet
should not be setting a Content-Length header because clients could hang
waiting for the content. However, clients should be smart enough to ignore
content-length header on a 304 by looking for the first empty line.
From
my googling, it looks like this is a reappearance of Jetty issue 283: http://jira.codehaus.org/browse/JETTY-283.
Looking at the code, the ProxyServlet appears to have been rewritten and the
bug reintroduced.
Thoughts?
-mike
Error! Filename not specified. | Mike Pilone | Software Architect,
Distribution | mpilone@xxxxxxx
| o: 202-513-2679 m: 703-969-7493