Re: CGP/1.0 specification

• Mail folder: WWW Talk Oct 93-present
• Next message: Rob McCool: "revised CGI/1.0 specification"
• Previous message: Rob McCool: "CGP/1.0 specification"
• Maybe in reply to: Rob McCool: "CGP/1.0 specification"

Message-id: <9311192226.AA18159@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Fri, 19 Nov 1993 16:26:28 -0600
In-Reply-To: George Phillips <phillips@cs.ubc.ca>
       "Re: CGP/1.0 specification" (Nov 18,  6:36pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: George Phillips <phillips@cs.ubc.ca>, www-talk@nxoc01.cern.ch
Subject: Re: CGP/1.0 specification

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