Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338807

Summary: ProxyServlet hang with 304 and Content-Length header
Product: [RT] Jetty Reporter: Mike Pilone <mpilone>
Component: otherAssignee: Project Inbox <jetty-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: gregw
Version: unspecified   
Target Milestone: 7.2.x   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Attachments:
Description Flags
TCPMon of Client to Proxy
none
TCPMon of Proxy to Backend none

Description Mike Pilone CLA 2011-03-03 08:21:57 EST
Build Identifier: 7.3.0.v20110203

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.

The issue on the Spring side (the backend servlet) is filed as https://jira.springsource.org/browse/SPR-8013


Reproducible: Always

Steps to Reproduce:
1. Setup a ProxyServlet.Transparent pointing to a jetty backend.
2. Install a webapp that will cache an image on the backend but will return a content length header on a 304.
3. Request the page with the image once through the proxy.
4. Reload the page with the image through the proxy.
5. Get a gateway time out on the 304.
Comment 1 Mike Pilone CLA 2011-03-03 08:23:19 EST
Created attachment 190261 [details]
TCPMon of Client to Proxy
Comment 2 Mike Pilone CLA 2011-03-03 08:23:47 EST
Created attachment 190262 [details]
TCPMon of Proxy to Backend
Comment 3 Mike Pilone CLA 2011-03-03 08:25:45 EST
After applying a workaround on the backend to force the content length to 0 (I couldn't remove the header completely), the ProxyServlet behaved as expected. So while I agree that this is a backend problem, RFC 2616 section 4.4 indicates that the client should be able to handle this situation and ignore entity headers on a 304 response. I tested from Client to Backend directly and Google Chrome was able to handle the 304 with a Content-Length header without an issue.
Comment 4 Greg Wilkins CLA 2011-04-01 00:03:15 EDT
content length ignored for 204,304 and 1xx responses

r2953