I'm not sure what the script map has to do with it really. PATH_INFO was
designed as another means by which to pass variables - an altenative to the
key=value, ampersand-seperated method. There's no reason for it to be treated
differently when using an extension handler, and so far, CF and ASP are the
only things I've seen treating it differently. ASP gets it very wrong by
returning a 404 if you include any path info - at least it does on two of the
hosting services I use. CF gets it a bit wrong by including the requested file
itself s further parsing is required to actually get to the variables you
want.
Php and mod_perl on the other hand, even when used in webserver api
environment both adhere to the cgi spec and return only characters after the
requested script. I can't test Php's IIS version right now though, so I'm not
sure how it behaves. I guess it's entirely possible it's a webserver thing and
not part of the scripting language itself.
> I don't think these semantics are used anymore. The 'old' interpretation
> of PATH_INFO made sense when people had CGI scripts living in /cgi-bin.
> When scripts are mapped based on a file extension and then run by an
> interpreter, the PATH_INFO (and PATH_TRANSLATED) variables are treated
> differently.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
