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
