Re: CGP/1.0 specification

Rob McCool (robm@ncsa.uiuc.edu)
Fri, 19 Nov 1993 16:26:28 -0600


/*
* Re: CGP/1.0 specification by George Phillips (phillips@cs.ubc.ca)
* written on Nov 18, 6:36pm.
*
* 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.

This is true, it makes FULL_URL frivolous. Unless there are any serious
objections, I'd like to remove it from the spec.

* 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?

This is what I had in mind.

I was thinking about it, and this is not really a protocol but an interface.
What do you all think about changing it to CGI/1.0?

* >*** 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).

The problem is that I'd like scripts to have the flexibility of returning
the header if they so choose, without the server deciding for them.

How about, instead of "Parse-header", changing it to "Gateway-protocol" and
making it a word such as "HTTP/1.0" or "CGI/1.0"? This does not help your
concern of header-parsing overhead, but I think we can't avoid it anyway.

* 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.
*/

See my response in another note...

--Rob