Summary: | IIS 6+JK 1.2.0+Tomcat 5.5.20 web app FORM based auth hangs | ||
---|---|---|---|
Product: | Tomcat Connectors | Reporter: | Jason Anderson <jasona> |
Component: | Common | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | major | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Windows XP | ||
Attachments: |
worker.properties
rewrite.properties uriworkermap.properties login.jsp isapi_redirect.log rewrite.properties uriworkermap.properties New set of logs with WireShark PCAP file ISAPI Redirector 1.2.20 with extended debugging isapi_redirect.log with debug version of .dll |
Description
Jason Anderson
2007-02-03 20:50:50 UTC
Created attachment 19505 [details]
worker.properties
Created attachment 19506 [details]
rewrite.properties
Created attachment 19507 [details]
uriworkermap.properties
Created attachment 19508 [details]
login.jsp
Created attachment 19509 [details]
isapi_redirect.log
Created attachment 19510 [details]
rewrite.properties
Created attachment 19511 [details]
uriworkermap.properties
The error you're getting is a socket timeout - e.g. JK is timing out trying to read from the request stream. This is probably due to a confusion between the user agent, IIS and JK about the content length available to read in the request. In this case, the incoming request seems to be indicating that there are 45 bytes to read, which JK is timing out on. Can you attach a trace of the HTTP traffic for the failed request - preferrably a TCP level trace with Wireshark/Ethereal, but an HTTP trace from something like Fiddler (http://www.fiddlertool.com/fiddler/) would help. Created attachment 19531 [details]
New set of logs with WireShark PCAP file
I should note that POST via IIS -> redirect -> JK is now failing for *some* other forms. One is another JSP login form and another is a standard submit/post form. It doesn't seem that HTTP POST via the director is stable [in my environment]. Can you also attach a pcap file concerning the connection browser to IIS? The conversations between browser (10.1.1.120) to IIS (10.1.1.103) to JK (10.1.1.10) are all in the same pcap. Created attachment 19533 [details]
ISAPI Redirector 1.2.20 with extended debugging
My reading of the pcap trace is that the HTTP is well formed, and that the 44
bytes of form POST data are in the original request packet - i.e. they should
already be available to IIS and be accessible from the ECB without a ReadClient
call.
There's some strangeness in the logs (namely the "() receiving data from client
failed..."), which may point to something bad as the worker name isn't being
printed, although the code looks fine and the worker name is printed
successfully in the error handler later.
I've attached a build of 1.2.20 that has extended debug statements around the
ISAPI ReadClient. This should give us an idea of whether this is a JK problem
or an IIS problem.
Basically if the ECB reports anything other than 44 total or < 44 available,
then it's an IIS issue.
Otherwise something is broken in JK.
Can you replicate the issue with this build and reattach the isapi_redirect.log
Created attachment 19534 [details]
isapi_redirect.log with debug version of .dll
It appears to be working now at least on W2K3 servers. I tried it initially on W2K3 server "A" with the new debug .dll and it failed. I then tried another W2K3 server "B" which IIS had clean config+redirector and it worked. I compared configs, and the only difference was that on the server "A" HTTP compression had been turned on at one point (supposedly it was turned off again - was off in IISAdmin, but metabase still had some differences). So I re-turned it off to be sure. And that's when POST started working again on both A and B. Or it could just be late (past midnight MST) or phase of moon. However, POST still hangs on Windows XP. If that's the only environment, then I can probably work around as it is only used for developer testing and not production. XP doesn't do HTTP compression. The logs attached indicate that IIS is at fault here - it's reporting 44 bytes total (which is correct), but none available (which isn't correct). Either the 44 bytes should be in the ECB, or the ReadClient should succeed. |