Re: CGI/1.0 tweaks

robm@ncsa.uiuc.edu (Rob McCool)
Message-id: <9312080846.AA04590@void.ncsa.uiuc.edu>
From: robm@ncsa.uiuc.edu (Rob McCool)
Date: Wed, 8 Dec 1993 02:46:39 -0600
In-Reply-To: George Phillips <phillips@cs.ubc.ca>
       "CGI/1.0 tweaks" (Dec  7, 12:14pm)
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: CGI/1.0 tweaks
/*
 * CGI/1.0 tweaks  by George Phillips (phillips@cs.ubc.ca)
 *    written on Dec  7, 12:14pm.
 *
 * So here I sit implementing my x-exec: URL scheme which I wish to make
 * compliant with CGI/1.0.  Naturally, I've run into a few problems.
 * First the no-brainer:  HTTP_ACCEPT -- since HTTP is going to change
 * to the proper MIME field separator (either , or ;), so should CGI.
 * 
 * I ran into a slightly stickier problem which doesn't necessarily
 * affect the spec but does have some implications for script writers.
 * It's the business about self-referencing URLs.  Think of a gateway
 * which serves some abstract URL sub-tree.  The gateway can do
 * absolute references in that tree with URLs of the form:
 * 
 * (1)	$SCRIPT_NAME/gateway/sub/tree
 * 
 * Now, we also have SERVER_NAME and SERVER_PORT so the gateway could
 * say:
 * 
 * (2)	//$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME/gateway/sub/tree
 * 
 * if it wanted to be pedantic.  So why the extra variables?  Because
 * gopher requests need them in order to do self-references.  In other

 * words, they're useless unless your SERVER_PROTOCOL is "gopher".

Not necessarily. Each of the items could be of value to some scripts. For
instance, if I have a specialized server running on port 9999 which uses the
same scripts the one on port 80 does, then the port number may be important.
The same goes for SERVER_NAME. 

 * What should the spec say?  Well, we could drop them or we could
 * say they're only set if the protocol is "gopher".  Either way
 * is fine by me.  What I feel is necessary is that (1) be _the_
 * method for self-referencing URLs.  That way, gateway scripts
 * can be used nicely as x-exec: scripts with 0 changes.
 */

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?

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. This is a serious
problem, and is a possible red flag for making CGI work for non-HTTP servers.

I can thus see two solutions, both are ugly:
1. Make the scripts ensure that they are running from an HTTP server when
returning URLs.
2. Make the non-URL servers (basically everything non-HTTP) handle URLs
coming back from scripts.

Unfortunately both are ugly. I would prefer (2), but that's probably only
because I'm not the one who has to implement it. It would make scripts a lot
simpler, though. John? Ideas?

--Rob