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