I was narrow-mindedly thinking that the gateway would only wish to
reference itself in HTML output where saying <A HREF=/foo/bar>link</A>
is sufficient because the client will fill in "http://a.machine:port".
I had forgotten "Link:" and other headers which need "complete" URLs.
My use of URL was incorrect.
>The problem I see here is not that there are extra variables, it's that
>sending back URLs to non-HTTP clients won't usually work.
Right. However, I'm not expecting that you can simply write a gateway
script which can spit HTML and have that translated by the server into
gopherese. I think it's sufficient to solve the problem that gateway
scripts can only self-reference themselves if they assume they're
being accessed via HTTP. How about this: drop SERVER_PORT and
expand SERVER_NAME to include the URL scheme, hostname and port.
A script then can create self-referencing URLs by saying:
$SERVER_NAME$SCRIPT_NAME$PATH_INFO
This will solve the problem in the x-exec: scheme and will have the
benefit of letting the scripts operate as long as whatever protocol
they're using gives them a URL and will understand their MIME object
output. Here's how a few URLs might break down:
SERVER_NAME SCRIPT_NAME PATH_INFO
http://a.host:99 /htbin/finger /phillips/cs/ubc/ca
x-exec://\bin\wrn /newsgroups/comp.sources.misc
dec-http://decnetaddr /htbin/finger /phillips/cs/ubc/ca
The only down-side to this is CGI scripts which wish to output
something that isn't HTML or WWW-MIME like. They're going to
have to work harder in parsing the SERVER_NAME so they can spit
out, say, a gopher directory. I see this as acceptable --
especially since it very nicely abstracts the access protocol.
Now, you might ask about SERVER_PROTOCOL. Well, I'd argue that's
independent of SERVER_NAME. Certainly x-exec: will tell you
the SERVER_PROTOCOL is HTTP/1.0 -- no reason not to since x-exec:
will give you the extra information on a POST and it will accept
full HTTP/1.0 repsonses. I'm sure the same would be true of
the hypothetical dec-http: scheme -- just the transport is different.
In that way, SERVER_PROTOCOL is a bit of a misnomer, but I
certainly can't think of a better name.
-- George