.. and the penny drops
>I didn't say anything about the purpose of CGI scripts. I said something
>about the intended purpose of PATH_INFO. I use CGI for much more than forms
>too, and in the future these other uses will become very important. I just
>don't think that having binary data in PATH_INFO is either a good idea or
>a necessary action.
Sorry, when you said "we can finally move away from using PATH_INFO
to convey state information to scripts and go back to using them for their
intended purpose" I assumed you meant CGI script because "their" didn't
seem to refer to PATH_INFO.
Taking that into account, I see that we have very different ideas
about PATH_INFO. I gather that you expect it to be a file relative
to the root of your document tree. This certainly clears up a few
things for me; I never did understand what PATH_TRANSLATED was until
I looked at the httpd source just now. To me, PATH_INFO is just state
for the script and has nothing to do with the server document tree
(a httpd server specific concept). For an example of how I typically
use PATH_INFO, see http://www.cs.ubc.ca/nhl Nothing there maps
to a real file.
>From there, I'm sure you could imagine some kind of CGI script
storing binary data in PATH_INFO. Certainly the author might
use a more compact encoding like base-64, but if they decide to
use the "standard" %-encoding, they'll be screwed.
I'm not sure we can reconcile our two views, but how about this.
PATH_INFO is just as it appeared from the "GET /url" command
(i.e., no un-escaping) and PATH_TRANSLATED is the unescaped version.
I think that would cover the different uses of PATH_INFO well.