Re: CGI/1.1 draft

George Phillips <phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 17 Mar 1994 21:04:45 --100
Message-id: <7804*phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Reply-To: phillips@cs.ubc.ca
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: George Phillips <phillips@cs.ubc.ca>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: CGI/1.1 draft
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1719

Rob said:
>But it does touch it... it has to make PATH_TRANSLATED.

.. 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.