Re: CGI/1.1 draft
john@math.nwu.edu (John Franks)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 1 Mar 1994 16:43:44 --100
Message-id: <9403011540.AA03251@hopf.math.nwu.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: john@math.nwu.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: john@math.nwu.edu (John Franks)
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: 1341
According to Rob McCool:
>
> To clarify on this point, I just went back and looked at the spec. again.
> The current implementations are in fact up to spec., as the specification
> has always read that PATH_INFO should be unescaped (dating back to Dec. 13
> last year). The notable exception is NCSA httpd 1.x which mistakenly
> converts + signs to spaces in file names.
>
> The question is then whether we should have PATH_INFO in fact be escaped, or
> unescaped. At any rate, changing this aspect of the specification will break
> things, so I'm leery of it.
>
I guess I would favor keeping current practice, but I would not object
violently a change in this area. I do want to make sure that the spec
is very specific on this point though. If PATH_INFO is unescaped we
must say so explicitly and say what this means, i.e. does unescaping
include '+' -> space translation or just the %hex decoding. My
understanding when I did this was that unescaping included both and that's
the way my server works. If this is wrong then I would like to fix
it. "URL decoding" might be a better term than "unescaping".
I like the idea of a data root directory environment variable. At
user request I have already implemented this as a non-standard feature
in GN.
John Franks Dept of Math. Northwestern University
john@math.nwu.edu