Re: CGI/1.1 draft (John Franks)
Date: Tue, 1 Mar 1994 16:43:44 --100
Message-id: <>
Precedence: bulk
From: (John Franks)
To: Multiple recipients of list <>
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