Re: CGI/1.0 tweaks

• Mail folder: WWW Talk Oct 93-present
• Next message: Kevin Altis: "HTML comments removed from spec.?"
• Previous message: Tony Sanders: "Re: comments on HTTP draft of 5 Nov 93 "
• In-reply-to: Rob McCool: "Re: CGI/1.0 tweaks"

Date:  8 Dec 93 13:09 -0800
From: George Phillips <phillips@cs.ubc.ca>
To: <robm@ncsa.uiuc.edu>
Cc: <www-talk@nxoc01.cern.ch>
In-reply-to: <9312080846.AA04590@void.ncsa.uiuc.edu>
Message-id: <7017*phillips@cs.ubc.ca>
Subject: Re: CGI/1.0 tweaks

Rob sez:
>Hang on, you're confusing me. If it's a self-referencing *URL*, then you
>should be able to include port and hostname any way since it is a URL. In
>what context are you building these self-referencing URLs? For the Location:
>header? For HTML links?

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