FW: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed

[Jason Reid <jr...@agency.com>]

Hi, I tried sending this directly to Gal Schacor,
but the message was unable to be successfully
delivered, so I decided to forward it onto
Tomcat-Dev.

	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		Email: jreid@agency.com
		http://www.agency.com

		"Do not meddle in the affairs of programmers, 
		 for they are subtle and quick to anger."


-----Original Message-----
From: Jason Reid 
Sent: Friday, May 12, 2000 9:49 AM
To: 'schacor@il.ibm.com'
Subject: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed


Hi,

I recently posted a message to tomcat-dev describing a
problem I had with IIS + Tomcat...that message has been
attached to the end of this one.

Anyway, I traced the behavior to the isapi filter,
did some logging, and found what I think was the problem.
In the comments, you say that the plugin uses a TLS to
pass values from the filter to the extension.

In the filter, the filter_ext_record_t rec was always
being successfully stored in the Tls.  However, in the
extension (function init_ws_service), sometimes the
TlsGetValue would return NULL.

Now, I don't know very much about programming C in
Windows, and I know even less about doing ISAPI Filters
and Extensions (yesterday was actually the first time
I'd even seen one!).  But I was left to assume that
perhaps a separate thread was invoking the extension then
had invoked the filter?  And in that case, I gathered,
the TlsGetValue would not find the filter_ext_record that
had been previously stored.

I went through Microsoft's Knowledge base, and found an
article on passing information from a Filter to an Extension.
One technique they suggested was the use of shared memory
blocks...I didn't want to introduce that sort of complexity.
However, for simple data values, the article said you could
also just add an Http header in the filter, which could be
read by the extension.  So I hacked in behavior for the
filter to add two headers, TOMCATURI and TOMCATWORKER
as a substitute for the values kept in the filter_ext_record.
I also modified init_ws_service to accept an LPEXTENSION_CONTROL_BLOCK
parameter, which it could use to get at the headers.

Using this technique for passing information, I was able to make
the bug disappear.

I've attached the modified jk_isapi_plugin.c for your perusal.
If it looks a bit like a late-night hack, that's because it
is one :)

	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		Email: jreid@agency.com
		http://www.agency.com

		"Do not meddle in the affairs of programmers, 
		 for they are subtle and quick to anger."


-----Original Message-----
From: Jason Reid 
Sent: Thursday, May 11, 2000 3:57 PM
To: 'tomcat-dev@jakarta.apache.org'
Subject: FW: Somewhat reproducable bug with POST


I posted this problem to tomcat-users a few days ago, but couldn't
really get any help.  After delving into the problem a little bit
more, I think I was able to isolate the bad behavior to the
isapi_redirect.dll.

On some occasions, when I try to post to a servlet running alongside
IIS, I get a 404 error.  If I do a refresh/repost of form data, 
the servlet executes fine the second time.

After delving into the Ajp12 handler source, I discovered that I
could log the AJP details.

I then visited the web application, and was able to capture the
logs of the error and then the subsequent success.  The AJP logs
for the two were identical, except for the URIs.  For the good
request, the 2 URI lines that were logged looked like:

AJP: URI: /app/servlet/controller/SubscriberProfile CP:null LP:null

For the bad request, however, the log showed:

AJP: URI: /jakarta/isapi_redirect.dll CP:null LP:null

Anyway, this bug is pretty much a showstopper for me, so I'm going
to delve into the C code and see if I can't turn anything up.
If, however, this catches the eye of anyone who is already familiar
with the code, and you have an idea of what might be occurring, I'd
appreciate any help you could give me.


	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		Email: jreid@agency.com
		http://www.agency.com

		"Do not meddle in the affairs of programmers, 
		 for they are subtle and quick to anger."


-----Original Message-----
From: Jason Reid 
Sent: Monday, May 08, 2000 7:14 PM
To: 'tomcat-user@jakarta.apache.org'
Subject: Somewhat reproducable bug with POST


I have Tomcat 3.1 hooked into IIS.

One "super-servlet" intercepts all requests made into
my system, reads the extra path info, and then dispatches
the request to another servlet.

Many of my servlets have their doGet() display a
page, with a form action that points to the servlet's
doPost().  This doPost(), after checking the input,
would dispatch the request to another servlet, or it
may simply call its own doGet().

Sometimes, however, when on the page displayed by the
original doGet, form submission does not work as planned.
Instead, I will get a message of the following form:

Error: 400
Location: /jakarta/isapi_redirect.dll
HTTP method POST is not supported by this URL

If I do a refresh right after getting this message, it
works fine.  It's also not entirely reproducable...sometimes
the process works without a hitch, sometimes it doesn't.  Oh,
and it only seems to happen under the various flavors of IE.

I have tried everything that I can think of...I've tried
modifying the "super-servlet", the individual processing
servlets themselves...nothing seems to work.  I was wondering
if anyone could help me find the cause of this bug...does
anyone know under what conditions this sort of message would
be returned?  Any help would be greatly appreciated...I'm at my
wits end.

	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		Email: jreid@agency.com
		http://www.agency.com

		"Do not meddle in the affairs of programmers, 
		 for they are subtle and quick to anger."