Re: CGI/1.0 status

luotonen@ptsun00.cern.ch (Ari Luotonen)
From: luotonen@ptsun00.cern.ch (Ari Luotonen)
Date: Thu, 2 Dec 93 10:56:00 +0100
Message-id: <9312020956.AA11673@ptsun03.cern.ch>
To: phillips@cs.ubc.ca, robm@ncsa.uiuc.edu
Subject: Re: CGI/1.0 status
Cc: www-talk@nxoc01.cern.ch


George:
>  * If "nph:scriptname" is the expected name of the script, then
>  * the ":" should be changed to...
>  * ... If, however, the "nph:" is stripped by server and
>  * it execs "scriptname", all is fine.

Rob:
> Good point. Mac systems will not like the : one bit. I'll change it to
> "nph-", are there any objections to that? VMS? I think DOS, OS/2, NT,
> and System 7 don't have any problem with it. I'm not sure about VMS.

I would do the opposite of what George suggested (stripping "nph:" off):
Why does nph: (or now nph-) have to be present in the URL at all? -- It's
information controlling the server.  I would prefer it being in the
script filename suffix, automatically added by the server when searching
for executable.  If you want to change a previously normal script to
an nph- script you would have to modify all the docs containing URLs
to that script.  If .nph is added by server no docs need to be changed.

I can see, however, the performance point of view.  But then again
.nph shouldn't be forbidden in URL -- if it's there then server knows
for sure right away that this is an nph script.  Only if the suffix
is missing it has to look for the actual script name.

This is how I'll handle the difference between current CERN daemon
interface and CGI/1.0 anyway.

As for the decoding/parsing issue -- I don't like having both preparsed
and full URL made available -- it's unnecessary duplication.  If the
script doesn't want preparsing then it gets it unparsed and that's it.
If it wants to have preparsed stuff that's what it gets (only).  If
there is an overflow somewhere then too bad, life is hard sometimes.
Like George said -- quick hacks need not cope with the craziest possible
argument to be useful.

>  * Anyhow, I think this is pretty much a tempest in a teapot.  Based on
>  * my experience in writing gateway scripts, I like the extra bit of
>  * decoding -- just seemed more convenient and never got in the way.
>  * Mind you, that was only for <ISINDEX> decoding.  Maybe FORMs decoding
>  * is less useful.  Maybe a split is in order:  decode ISINDEX stuff
>  * 'cause it won't overflow and is semantically simply, don't decode
>  * FORMs stuff cause there's a good chance it'll be too big anyway
>  * and it's hard to decode the information into a usable form.
>  */
> 
> This, I think, is a good idea. I would agree to making ISINDEX queries
> decoded, but not FORMs queries (at least not with GET).
> 
> Ari?

Sounds ok to me.

-- Cheers, Ari --