Re: 404 handler mkicks in before ISAPI filter
From: Yoram Ayalon (anonymous_at_discussions.microsoft.com)
Date: 03/16/04
- Next message: Srini: "RE: IIS6 fails to start - error 2147500034 (0x80004002)"
- Previous message: KMS - Brett Anderson: "Re: I'm missing the damn asterisk!"
- In reply to: Wade A. Hilmo [MS]: "Re: 404 handler mkicks in before ISAPI filter"
- Next in thread: David Wang [Msft]: "Re: 404 handler mkicks in before ISAPI filter"
- Reply: David Wang [Msft]: "Re: 404 handler mkicks in before ISAPI filter"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 16 Mar 2004 07:01:16 -0800
Wade,
Thanks again for the help. Everything you say if of course correct. However, I do have control over the URLs that will be sent my way, since they are all generated by my server application. The following is true for my application:
The application does NOT create a URL that contains a folder name with no filename.extension. The only place where you have no filename.extension is if it just contains the hostname with no folders. If a user would manually change a URL so it ends with a folder name without the filename he will get a 404 and this is OK with me.
The application does not generate a URL that contains a “.” besides as a separator between filename.extension
My server application does not generate a URL that contains a “/” inside a query string.
So I am applying the following rules for my ISAPI filter, and so far, after a week of testing they seem to hold:
Any empty URL or one that contains a “?” (question mark ) is ignored.
Any URL that contains “_vti” is ignored (for compatibility with Front Page Server Extensions)
The filter works backwards until it finds a “.” (dot) or until the start of the url string, replacing “/” with “=” , “&” and “/” as needed. I make sure I have an even number of “/”
Regards,
Yoram Ayalon
----- Wade A. Hilmo [MS] wrote: -----
Hi Yoram,
The value you are getting for the URL is coming straight from the client.
It is normal that the client does not send the host name as a part of the
URL. After all, the client only needs the host name to be able to connect
to the server (unless the client is configured to use a proxy, in which case
you would see the whole URL, including protocol and host name.) Your filter
will need to be able to deal with this. Note that you can probably get the
host name from the "Host:" header, although it's not guaranteed that
HTTP/1.0 clients will send you one (it's required that an HTTP/1.1 client
include a host header.)
I should point out here that it's not possible to "look" at a URL and
separate the path info from it. It sounds like you are making some
assumptions that won't be valid on a closer inspection. For example,
consider the following URL. I assume that this URL would represent the case
you mean when you say "to finish with an explicit filename before any
optional parameters":
http://server/foo.bar/goo
The client will send you "/foo.bar/goo" as the header. What does that mean?
Does it mean that "foo.bar" is a file, and "goo" is path info?
Does it mean that "foo.bar" is a directory and "goo" is a file in that
directory?
Does it mean that "foo.bar/goo" is a directory, and you want the default
file in that directory?
Does it mean that "/foo.bar/goo" is path info to be given to the default
file in the root directory?
You can't tell without knowing a whole lot about both how the server is
configured (ie. how to map to a physical directory, whether there is a
script mapping, etc.), and how the physical directory structure is laid out.
Unfortunately, in PREPROC_HEADERS, none of this information is available to
you. This information would be available in SF_NOTIFY_AUTH_COMPLETE, but I
suspect that the file existence verification happens before AUTH_COMPLETE.
I realize that this doesn't necessarily help you with the final resolution,
but I want to be sure that you know the full challenge of what you are
trying to do. I do not believe it's possible to write a generic solution.
If you know your clients well enough, though, you may be able to make some
assumptions about what they are trying to do.
Thank you,
-Wade A. Hilmo,
-Microsoft
"Yoram Ayalon" <anonymous@discussions.microsoft.com> wrote in message
news:972F9D5A-7153-467C-8F1F-3597F57BC7F8@microsoft.com...
> Wade,
>> You are right! I installed debugging code in my filter and verified I only
get the part of the URL after the host name.
> So, unless there is a way to get the host name part, and in my case its
not constant but could be one of many pointing to the same server, I can
make this work ONLY if I make sure all URLs to my server either contain only
hostname (plus optional params in format /param1/value1/....) OR, if they
contain folders, to finish with an explicit filename before any optional
parameters.
>> in any case this is my call to SetHeader :
>> pHeaderInfo->GetHeader(pCtxt->m_pFC,"url", url, (unsigned long *)&len);
> //allocate the right amount of memory
> url = (char *) pCtxt->AllocMem(len+2);
>> // now get the url string
> if ( pHeaderInfo->GetHeader(pCtxt->m_pFC,"url", url, (unsigned long
*)&len) )
> ...
> ... code snipped...
> ...
> if (replace) {
> pHeaderInfo->SetHeader(pCtxt->m_pFC, "url", url);
> }
>> thanks,
> yoram ayalon
>
- Next message: Srini: "RE: IIS6 fails to start - error 2147500034 (0x80004002)"
- Previous message: KMS - Brett Anderson: "Re: I'm missing the damn asterisk!"
- In reply to: Wade A. Hilmo [MS]: "Re: 404 handler mkicks in before ISAPI filter"
- Next in thread: David Wang [Msft]: "Re: 404 handler mkicks in before ISAPI filter"
- Reply: David Wang [Msft]: "Re: 404 handler mkicks in before ISAPI filter"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|