ISAPI Filters, Extensions and a NON DEFAULT Web Site - HELP!

[Nick Knight]

Hello,

Hopefully these are the proper groups in which to post this question.
They were the best fit from what I found available. I'll apologize in
advance of somewhere else would have been better.

I have a DLL that we've been calling a "plugin". After analyzing the
code, I see that it is BOTH an ISAPI Filter and an ISAPI Extension. It
was written long ago, and seems to work ok, until you use a NON DEFAULT
web site.

Here are the basics. We filter URL's that contain a specific string, and
record the original URL in the header, and set the URL to "/scripts/".
This apparently triggers IIS's internals to say that this is meant to be
passed to an extension, and our HttpExtensionProc() does (usually) get
called next. We use the saved original URL in the header to do what we
need to do.

This works well for IIS 4.0 running in personal mode (non Server install).
It also works in a full NT Server install as long as the "default" web
server is used.

The requirements call for this all to be passed to a unique, non-default
web site setup. Here's where it doesn't work. Basically, I've used
Internet Service Manger to create a new web site. I've tried it different
ways; either using a different port or STOPPING the default and starting
this new one on port 80. Anyway, as far as I can tell, ALL SETTINGS,
including the document root, are the same for both sites. (NOTE that the
filter is installed globally, at the "machine" level, but I've also tried
all the permutations of this). Yet, the non-default web server's
extension proc never gets called. All normal HTML files load as expected,
in all cases.

I've added much logging (I've found now how to debug into this, but the
logging has told me where it breaks for now). The page request IS
getting into our filter proc, and it *is* being filtered. However, the
"/scripts/" URL doesn't seem to trigger the call to HttpExtensionProc().

Thinking that, maybe, I needed a /scripts/ dir and the proc DLL in that
dir, I added this as a subdir to the docroot. Well, now accessing this
page wants to download the DLL!

I've been reading through two ISAPI books, but there's little I've found
about exactly how an extension is triggered. Well, some, but it doesn't
explain why it would work for the default site, but not for an alternate
site configured identically (as far as I can see).

Any ideas? Thanks in advance,

Nick
--
-----------------------------------------------------------
Nick Knight <ni...@secant.com> http://nick.secant.com
Senior Software Engineer
Secant Technologies, Inc. http://www.secant.com
-----------------------------------------------------------

[Nick Knight]

No answers yet :(. I knew the question was too long!

Anyway, there is a correction ... the URL is remapped to
"/scripts/dsh_iis35.dll", where dsh_iis35.dll is our DLL name. This has
already been loaded as a filter from the path
"c:\inetpub\scripts\dsh_iis35.dll" and that alway works. The EXTENSION
proc only gets triggered when using the DEFAULT web server. Move the code
over to a "new" web server, and it does the filtering, just never calls
HttpExtensionProc()!

Thanks in advance,

In <39a58def$1$avpx$mr2...@client.ce.news.psi.net>, on 08/24/2000

[Henke Kofot]

Im not sure I understand this right, but since I've come across code that is
both EXTENSION and FILTER, maybe I can give you a clue. I believe the
'filter' part does a redirect to '/scripts/dsh_iis35.dll'. Then the IIS
thread leaves the filter, the client gets a redirct and calls the extension,
which happens to be in the same code and dll, but I don't think that is
important. It could be any extension. The main reason to do this is to be
able to share global data (like for instance a cache map) between the filter
and the extension.
The problem could be that the execute permissons of the /scripts/ directory
is to allow executions of scripts only, instead of 'scripts and
executables'. That would explain why the web server think you want to
download the dll. Maybe you need to change the redirection to anther
catalog, if you don't want to use the Default Web Site.

Henric Sjöqvist

"Nick Knight" <ni...@secant.com> wrote in message
news:39a68dfe$2$avpx$mr2...@client.ce.news.psi.net...