Hi,
How is it possible to identify if the request is for static pages, i.e.
html or not ? I understand that in the IIS I can configure html files
to be handles by .net for example so the extension of the file in the
URL is not ok.

Thanks,
Gilad.

Hi Gilad,

Can you be more specific about what you are asking?  Are you trying to do
this with code?  From the client or from the server?  With a network
sniffer?

I can tell you that this is impossible from the client or as an observer on
the network.  The way HTTP works is that the client sends a request and the
server sends a response.  There is nothing in the protocol about the nature
of how the server produces the response, so the information simply doesn't
exist on the wire.

Thank you,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1147869675.049836.226300@u72g2000cwu.googlegroups.com...
> Hi,
> How is it possible to identify if the request is for static pages, i.e.
> html or not ? I understand that in the IIS I can configure html files
> to be handles by .net for example so the extension of the file in the
> URL is not ok.
>
> Thanks,
> Gilad.
>

Hi,
Forgot to write that I'm hoping to get that information in the ISAPI
filter that I'm using.

Thanks,
Gilad.

Hi Gilad,

You can do this on IIS 6 only.  Earlier IIS versions do not support the
HTTP_FILTER_URL_MAP_EX structure below, which is necessary to get script
mapping information in a filter.

To do it, use SF_NOTIFY_URL_MAP.  On the first, and only the first, URL_MAP
notification for a given request, you can use the HTTP_FILTER_URL_MAP_EX
structure to determin this.

You need to look at the following members:

dwFlags - If the MD_ACCESS_EXECUTE bit is set, then you look at
pszPhysicalPath and find the file extension.  If the file extension is
".exe", ".com", or ".cgi", then the request is for a CGI.  If the file
extension is ".dll" or ".isa", then the request is for an ISAPI extension.

pszScriptMapEntry - If this value is a non-empty string, then the request is
script mapped to either an ISAPI or CGI.  You can use the file extension
rules above to know which.

Note that it's still possible for some filter to send a response to the
request.  There is no practical way to tell if this will happen from with
any code other than the code that does this.  This is something of a corner
case, since we explicitly tell people that they should not handle requests
with a filter.

I hope that this helps,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1147933686.606096.56280@y43g2000cwc.googlegroups.com...
> Hi,
> Forgot to write that I'm hoping to get that information in the ISAPI
> filter that I'm using.
>
> Thanks,
> Gilad.
>

Hi,
I understand that pszScriptMapEntry can help identify CGI,ISAPI or
something else. something else can be asp pages. I want to know if it
is a static one, i.e. not running other components - simple html file.

Maybe if dwFlags is not MD_ACCESS_EXECUTE its a static page ? or
MD_ACCESS_EXECUTE is also for asp ?

Thanks,
Gilad.

Hi Gilad,

The rules that I listed in my last post account for all possibilities.  Note
that I didn't list all the possible permutations that could be configured,
but they are all accounted for.  The only thing that will get you with this
would be the case that I called out where another ISAPI filter sends out the
response in a way that we don't expect.

All dynamic content (except the filter case I mentioned) has to go through
either an ISAPI extension or a CGI.  In the case of ASP, the ".asp"
extension is script mapped to an ISAPI extension called
"c:\windows\system32\inetsrv\asp.dll" (or whatever the path is on your
particular machine.)

For ASP pages, you will see the above path to asp.dll in the
pszScriptMapEntry member.  Even in the case someone has set up their server
so that .htm files are handled by ASP, you would see the path to
"...\asp.dll".  For ASP.NET, you will see some path to
"...\aspnet_isapi.dll".  For Perl or Cold Fusion or whatever, you will see
the path to their ISAPI extension.

Thank you,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1148218331.171147.267290@i40g2000cwc.googlegroups.com...
> Hi,
> I understand that pszScriptMapEntry can help identify CGI,ISAPI or
> something else. something else can be asp pages. I want to know if it
> is a static one, i.e. not running other components - simple html file.
>
> Maybe if dwFlags is not MD_ACCESS_EXECUTE its a static page ? or
> MD_ACCESS_EXECUTE is also for asp ?
>
> Thanks,
> Gilad.
>

Thanks again, but I can't find HTTP_FILTER_URL_MAP_EX, only
HTTP_FILTER_URL_MAP. If its not in httpfilt.h where can I get it ?

Hi Gilad,

As I mentioned in my first reply, this capability is new to IIS 6.  You need
the latest version of the Platform SDK.

Thank you,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1148489821.913682.218380@38g2000cwa.googlegroups.com...
> Thanks again, but I can't find HTTP_FILTER_URL_MAP_EX, only
> HTTP_FILTER_URL_MAP. If its not in httpfilt.h where can I get it ?
>

Ok, I updated the platform sdk and I see the struct.

The problem is that I get an exception trying to access
pszScriptMapEntry. Is there something I should update on the server

The platform and the dev environment are on one computer (windows xp)
and the tests are on the 2003 server

Thanks,
Gilad.

Have you looked at it in a debugger?  What is the pointer value of
pszScriptMapEntry?  Does it look like valid memory for the process?

Thank you,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1148820388.148349.59270@j33g2000cwa.googlegroups.com...
> Ok, I updated the platform sdk and I see the struct.
>
> The problem is that I get an exception trying to access
> pszScriptMapEntry. Is there something I should update on the server
>
> The platform and the dev environment are on one computer (windows xp)
> and the tests are on the 2003 server
>
> Thanks,
> Gilad.
>

I can access pszPhysicalPath that is an older member of the struct.
That is why I thought maybe there's a binary file that I should copy to
the test env.

Thanks,
Gilad.

There is no binary.  IIS 6 just extends it's internal structure beyond what
earlier IIS versions had.  The updated header file with the new struct just
gives access to this extended data.  (And if you try using this structure on
an earlier IIS version, it could very well crash...)

What did using a debugger reveal?

Thank you,
-Wade A. Hilmo,
-Microsoft

"gilad"  wrote in message
news:1148830182.000535.125820@38g2000cwa.googlegroups.com...
> I can access pszPhysicalPath that is an older member of the struct.
> That is why I thought maybe there's a binary file that I should copy to
> the test env.
>
> Thanks,
> Gilad.
>

pszPhysicalPath points to null where values from the previous structure
are ok.

Thanks,
Gilad.

What do you know ... it started to work. I'm not sure what was the
problem, maybe several versions of the filter/extension headers.

Thanks.