This is related to bug 48763. We are experiencing intermittent timeouts of POST requests with transfer-encoding: chunked. These failures occur very frequently after IIS has shutdown ISAPI_Redirect because of a period of inactivity. The next request triggers IIS to restart the redirector, and that request and several more that queue up behind it fail. JK puts the worker in error state. Eventually, the failure gets back to the client. I've done some tracing and this is what I see: - The requests that fail do arrive at the Tomcat. Tomcat times out trying to read the post body. - The failing AJP request messages from ISAPI both a positive content-length and "transfer-encoding: chunked". Ordinary requests don't have the c-l. My guess is, 1) If IIS is able to receive and assemble the chunked body before JK asks for it, IIS reports the actual size instead of -1. 2) This possibly occurs while ISAPI_Redirect is reinitializing because there is time for IIS to build the body before JK needs it. 3) When this occurs, the JK end of the APR connection waits for a get-body-chunk message. The Tomcat APR sees the positive c-l and waits for the free body chunk that non t-e requests send.
er, where I wrote APR, please read AJP. It's been a long day.
I think this has the same root cause as bug 50975, and I think the behaviour is as Bruce suggests. It looks like IIS is adding a CONTENT_LENGTH server variable, where there was no Content-Length in the original request under some conditions (my guess is when the entire request is able to be decoded into the available buffer). The fix will be to mask the synthetic CONTENT_LENGTH out when Transfer-Encoding: chunked is present in the request.
*** This bug has been marked as a duplicate of bug 50975 ***