> Actually, IIS does NOT "shove the .cfm file to the CF parser
> sight unseen"
>
> IIS never touches .cfm files unless it's mis-configured, or
> has been told to check for the file's existence before handing
> the request off. (Even then it does not actually open the file,
> it just looks for it.). Why do you think CF has its own 404 error
> pages?
>
> When IIS gets a request for a file ending in .cfm, it passes
> the *request* to CF. CF opens the file all by it's lonesome. You
> can prove this by running CF under a user account and giving CF
> permission tot he files, but not IIS. (or the other way around
> if you like errors)
This doesn't seem to be exactly correct. IIS does check file ACLs - it has
to. It performs an impersonation using either the anonymous user account, or
using the authenticated user account when Basic Authentication or NTLM
Authentication are required. If the CF service has read/execute rights to a
file, but the IIS impersonation user account doesn't, IIS will return a 401
error message - access denied. I tested this by creating a user account,
running CF with that user account, removing permissions from a specific file
except for that user account, then attempting to access the file using
anonymous access first, then Basic Authentication.
Of course, you could make the argument that reading a file's ACL isn't quite
the same thing as reading the file itself.
I'm not sure how this plays out when you request a nonexistent CF script; CF
obviously returns the fake 404 error message. I don't know what the order of
events is for this.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
