Bug 48940 - IIS to Tomcat occasionally fails on POST with T-E chunked header
Summary: IIS to Tomcat occasionally fails on POST with T-E chunked header
Status: RESOLVED DUPLICATE of bug 50975
Alias: None
Product: Tomcat Connectors
Classification: Unclassified
Component: isapi (show other bugs)
Version: unspecified
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2010-03-18 20:22 UTC by Bruce G. Stewart
Modified: 2011-04-11 04:17 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Bruce G. Stewart 2010-03-18 20:22:54 UTC
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.
Comment 1 Bruce G. Stewart 2010-03-18 21:50:34 UTC
er, where I wrote APR, please read AJP.

It's been a long day.
Comment 2 Tim Whittington 2011-04-10 16:48:54 UTC
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.
Comment 3 Tim Whittington 2011-04-11 04:17:53 UTC

*** This bug has been marked as a duplicate of bug 50975 ***