Re: CGI/1.1 draft
robm@ncsa.uiuc.edu (Rob McCool)
Errors-To: listmaster@www0.cern.ch
Date: Fri, 18 Mar 1994 09:32:21 --100
Message-id: <9403180827.AA01868@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: robm@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: robm@ncsa.uiuc.edu (Rob McCool)
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: 2462
/*
* Re: CGI/1.1 draft by George Phillips (Tel (604)-822-4230)
* written on Mar 17, 11:56am.
*
* 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.
Actually, that's the another intended purpose. Right now, you have
/nhl/93-94/sched/foo mapping to the schedule for foo, which I assume goes
through a master schedule file and pulls out the relevant portions. Now,
what if, six months from now, that master schedule gets way too large and
you can no longer afford to search through it for each query? Now, you can
split it into files and make sched a directory with foo, bar, or the
schedules for whatever team you're using, and remove the script all
transparently.
* >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 still draw the line at binary data, sorry. If someone really wants binary
data in there they should encode it a different way.
* 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.
*/
But we can't do that, it will break existing scripts which may depend on
this behavior. I simply do not want to do that and field the questions of
WHY IS MY SCRIPT BREAKING IT WAS WORKING IN CGI/1.0??? for something which I
do not view as an important issue.
In addition, future versions of CGI must be backward compatible with old
versions of CGI. This is not just because we felt it was a good idea, it's
because CGI scripts have no way of telling the server what version of CGI
they run under, they can only see after their execution what the CGI
revision the server is compliant with.
--Rob