Mark, we could never get that combo working (IIS 5.X, Tomcat 4.X, JK
connector, HTTP POST). We ended up going to JK2 and all was resolved.
Shocking that it didn't work in the first place, but nevertheless, there
is a solution...
Rick Bullotta
CTO
Lighthammer Software (http://www.lighthammer.com)
-Original Message-
From: Mark E. Palandri [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 9:12 PM
To: [EMAIL PROTECTED]
Subject: IIS 5.0 Redirector Strangeness
I am currently developing a WebDAV server for our repository and it
seems to work fine when accessed through Tomcat 4.0.4 directly (i.e.
using port 8080). I've got the servlet mapped to a sub-directory of the
root (like the /examples example), and all the HTTP request methods sent
to a URI rooted at that sub-directory get through to my servlet just
fine.
I then tried setting things up to that I could access the servlet
through IIS 5.0. I followed the instructions in the IIS How To and
managed to get things limping along. Using a generic WebDAV client (say
the one that comes with Slide), all requests got through to my servlet.
But, when accessed as a Web Folder in the Windows explorer, I could see
that the OPTIONS method was making it to my servlet, but for some reason
the subsequent PROPFIND to the very same URI was failing with a 403
(Forbidden).
I did some digging around and it turned out that the problem was that
the Web Folder client was including a Translate: f header, which
apparently blocked the request at the isapi_redirector.dll. I searched
some more and saw something about this being a bug in IIS 5.0 and that a
fix had been made to the isapi_redirector.dll to work-around the
problem. The isapi_redirector.dll I was using was apparently the one
from several years ago that was distributed with Tomcat 3, and it didn't
have the fix.
I then went out to the latest jakarta-tomcat-connectors build of jk
(v1.2.2) and picked up the new version of isapi_redirector.dll. I
replaced the old one with the new one and without modifying anything
else, restarted IIS and Tomcat.
The results were odd. Now, the OPTIONS request gets blocked with a 500
(Internal Server Error), but the PROPFIND gets through to my servlet
just fine. I then checked some of the other methods and saw the
following
pattern:
failed: OPTIONS, PUT, DELETE
succeeded: PROPFIND, LOCK, UNLOCK, GET, MKCOL
I can understand why PUT and DELETE might be blocked by some sort of
write-constraint, but why is OPTIONS failing? If anyone can cast any
light on how I can get the new redirector to send *ALL* requests through
to my servlet, I'd appreciate hearing from you.
Thanks in advance,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]