Re: CGP/1.0 specification

George Phillips ([email protected])
18 Nov 93 18:36 -0800


It's useful for scripts to know what part of the URL was used to invoke
them (Rob suggested $SCRIPT_NAME before). That information is currently
implicit in the spec. It can be derived by looking at the first
length(FULL_URL) - length(PATH_INFO) characters of FULL_URL. If
this is true, that's fine, but maybe we'd rather just have
SCRIPT_NAME and PATH_INFO and drop FULL_URL in favor of it the
simple $SCRIPT_NAME$PATH_INFO derivation. Or have all 3, whatever.

A few other comments:

>GATEWAY_PROTOCOL: The revision of this spec to which the server complies

Why not make this a mime-like typename, say "CGP/1.0" for this version?

>*** The script's STDOUT
...
>If the script returns a header line of "Parse-header: false", the
>server will pass the rest of the output stream directly to the client.

This is not really part of the protocol, but if the server had some
way to tell that the script was always going to do it's own headers,
we could avoid the extra overhead of having the server chop the
(constant) "Parse-header: false\r\n\r\n" bit and re-copying the data.
I suppose it would save a little cross-configuration if the server
told the script what it expected. That begs for breaking the
GATEWAY_PROTOCOL variable into GATEIN_PROTOCOL and GATEOUT_PROTOCOL.
We still only have "CGP/1.0" for GATEIN_PROTOCOL, but we'd have
"CGP/1.0" for GATEOUT_PROTOCOL where the server looks at things and
"HTTP/1.0" for GATEOUT_PROTOCOL which means do it yourself
(or HTTP/0.9).

As to the question of whether Location: should interpret a virtual
of real pathname, I'd say that it should be virtual. If the
script wants to output a real path name, it can "cat /a/real/path/name".
Also, the virtual path name gives it the flexibility to activate
some other gateway.

-- George