Firefox, Squid and missing Content-Length
Archived post from 2009, recovered from my old blog. The technology described here is probably out of date. Original at the Internet Archive.
Something from my professional ground this time.
Problem description
- issue with portlet application running on WebSphere Portal 6.0.
- one of the application portlets launches a popup window after pressing Launch button, but the window does not show up on Firefox 3.0. However it works as expected on other browsers.
Facts gathered during diagnosis
-
the customer accesses the application on portal via the following components sitting in between:
- proxy server (Squid)
- TAM (Tivoli Access Manager)
- IHS (IBM HTTP Server)
-
browsers confirmed to be working properly:
- Firefox 3.5
- Internet Explorer 6
- Internet Explorer 7
-
browser used to recreate the issue – Mozilla Firefox 3.0.13
-
tracing of FF requests using Fiddler shows that after pressing Launch button an AJAX request is sent by the browser
-
the request does not hit TAM machine (there is nothing in TAM nor HTTP server logs) so it is handled completly by Squid itself
-
the response from Squid contains information 411 Length Required
-
the request sent by FF does not contain Content-Length header indeed
-
according to a section 4.4 of RFC2616 (specification of HTTP protocol):
- “For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.”
-
looks like Squid according to that sentence insists on receiving a valid Content-Length header by sending error 411
-
there was also a bug 1861 reported in Squid bugzilla which described exactly the same problem with Squid and Firefox but it was closed as the Firefox bug not Squid bug
The above facts showed that it was a Firefox who seemed to be a culprit here.
Digging into the details more I found out that the problem occured when Firefox was trying to send AJAX request with empty body which was represented by a javascript code:
xmlhttpequest.send(null)
In that case it did not send Content-Length header (although it should) and Squid rejected that request.
Solution
The workaround was to modify the portlet to send a dummy request body which fortunately did not break anything else in the application:
xmlhttpequest.send(“foo=bar”)