Re: CGI/1.0 tweaks

Rob McCool (robm@ncsa.uiuc.edu)
Wed, 8 Dec 1993 02:46:39 -0600

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