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