Wildcard extension mappings are NOT better than raw data filters...

Okay, so I have a raw data filter that I'm trying to port over to IIS
6. I'm going with the recommended wildcard extension rather than a
filter this time.

Problem: When ssinc processes includes, my wildcard extension doesn't
get called for the included files.

Now I know what you're thinking... "How picky can you be? Your
extension will get called BEFORE ssinc, so you can do whatever you
want, right?"

Well, not exactly. What I WANT is to be able to act on each included
file in turn before ssinc tries to spit it out to the browser. In a
good ol' raw data filter, I could just subscribe to url map
notifications and I could act on each path before ssinc got its grubby
little hands on it.

As it is, I'm stuck having to parse the file(s) myself (recursively, I
might add) looking for server side includes before I ever even pass the
request off to ssinc using HSE_REQ_EXEC_URL.

Now I realize that this is a feature, not bug. That's just how it
works. I understand that I'm probably the only person in the world who
cares about this. But in the remote case that I'm not, is there anyone
out there who knows a nifty way for me to be able to act on the paths
as ssinc gets to them (in an extension, not a filter mind you) rather
than doing all the parsing myself.

Thanks in advance for any help,

Doug

David
Fri May 27 23:17:51 CDT 2005

The correct recommendation is that you port READ raw data filters to
wildcard application mappings on IIS6. If you find a Microsoft
recommendation to replace SEND raw data filters with wildcard application
mappings, please give me a URL and I will get it corrected.

I think your current ISAPI filter uses UrlMap and SendRawData. Neither event
can be replaced by HSE_REQ_EXEC_URL. HSE_REQ_EXEC_URL is good at replacing
ReadRawData, PreprocHeaders, Authentication, AuthComplete events.

So, I think everything you observe is by-design, and I would stick with your
current filter on IIS6.

And in general, there is no good way to intercept the filesystem calls made
by an IIS module in the manner you describe ( act on each included file in
turn before ssinc tries to spit it out to the browser). You are lucky that
the ISAPI used PATH_TRANSLATED server variable prior to opening files, and
resolving that variable triggers UrlMap events.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Doug" <dougforrest@yahoo.com> wrote in message
news:1117224161.894627.256790@o13g2000cwo.googlegroups.com...
Okay, so I have a raw data filter that I'm trying to port over to IIS
6. I'm going with the recommended wildcard extension rather than a
filter this time.

Problem: When ssinc processes includes, my wildcard extension doesn't
get called for the included files.

Now I know what you're thinking... "How picky can you be? Your
extension will get called BEFORE ssinc, so you can do whatever you
want, right?"

Well, not exactly. What I WANT is to be able to act on each included
file in turn before ssinc tries to spit it out to the browser. In a
good ol' raw data filter, I could just subscribe to url map
notifications and I could act on each path before ssinc got its grubby
little hands on it.

As it is, I'm stuck having to parse the file(s) myself (recursively, I
might add) looking for server side includes before I ever even pass the
request off to ssinc using HSE_REQ_EXEC_URL.

Now I realize that this is a feature, not bug. That's just how it
works. I understand that I'm probably the only person in the world who
cares about this. But in the remote case that I'm not, is there anyone
out there who knows a nifty way for me to be able to act on the paths
as ssinc gets to them (in an extension, not a filter mind you) rather
than doing all the parsing myself.

Thanks in advance for any help,

Doug

Doug
Sat May 28 09:01:53 CDT 2005

Thanks for the reply David. Let me clear a couple of things up.

I am using ReadRawData, PreProcHeaders, UrlMap, EndOfRequest, and
SendResponse. I'm not using SendRawData.

I suppose I am "lucky" as you said that ssinc (from Microsoft) uses
PATH_TRANSLATED for each path. Otherwise my existing filter wouldn't
work. Of course the other web servers that my filter supports (iPlanet,
Apache) both have equivalent functionality that doesn't require any
luck.

The problem is that I have to port my filter over to an extension
because of the ReadRawData part of it. This inability to act on each
path as it is accessed by ssinc is just an unfortunate side effect. I
understand from your update that this is probably going to be a pain to
work around, but at least I know where I stand.

Thanks

Doug

David
Sat May 28 16:21:52 CDT 2005

I would use a combined ISAPI Filter/Extension DLL to handle both tasks.
Change the ReadRawData (and possibly PreprocHeaders, depending on what you
are doing) to be in the ISAPI Extension wildcard mapped, and leave the other
portions in the ISAPI Filter since it is better suited. Context can be
shared between the two (see posts in the
microsoft.public.platformsdk.internet.server.isapi-dev for details on that).

In general, IIS is abstracting the URL namespace side of things, not the
Filesystem/OS side of things, so it isn't going to force a module to use a
trappable "CreateFile" call to be able to affect what the module thinks it
is reading, for example. It can be argued either way from a design
perspective -- depends on what you define as the "environment".

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Doug" <dougforrest@yahoo.com> wrote in message
news:1117288912.987621.245010@g49g2000cwa.googlegroups.com...
Thanks for the reply David. Let me clear a couple of things up.

I am using ReadRawData, PreProcHeaders, UrlMap, EndOfRequest, and
SendResponse. I'm not using SendRawData.

I suppose I am "lucky" as you said that ssinc (from Microsoft) uses
PATH_TRANSLATED for each path. Otherwise my existing filter wouldn't
work. Of course the other web servers that my filter supports (iPlanet,
Apache) both have equivalent functionality that doesn't require any
luck.

The problem is that I have to port my filter over to an extension
because of the ReadRawData part of it. This inability to act on each
path as it is accessed by ssinc is just an unfortunate side effect. I
understand from your update that this is probably going to be a pain to
work around, but at least I know where I stand.

Thanks

Doug