So, let me emphasize something and make a promise.
First, the "a" in NCSA httpd version numbers is still there because I
consider the software alpha software. We're still working with the scripts
interface (and other aspects of the server) and trying to make it as
powerful as possible.
With that in mind, I'll make this promise. *Whatever script interface is in the
official NCSA httpd 1.0 will stay there.* If you have scripts which you
don't want to rewrite many times, you may wish to stay with NCSA httpd
1.0a3.2. I will try to make 1.0's release as speedy as possible (within 2
weeks I hope). At that point, if any changes are made to the scrip
interface, they will be backward compatible.
So, I'd like to open up the discussion of what should be in the script
interface to the script writers. Attached is a number of suggestions which
have been brought up and which I am considering supporting in the finalized
script interface. As always, we welcome your ideas and comments.
--Rob
>From robm Sun Nov 14 18:41:06 1993
From: robm@void (Rob McCool)
Date: Sun, 14 Nov 1993 18:41:06 -0600
In-Reply-To: George Phillips <phillips@cs.ubc.ca>
"script support" (Nov 14, 4:18pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: George Phillips <phillips@cs.ubc.ca>, <httpd@ncsa.uiuc.edu>
Subject: Re: script support
Cc: sanders@bsdi.com
Status: OR
/*
* script support by George Phillips (phillips@cs.ubc.ca)
* written on Nov 14, 4:18pm.
*
* I was just playing with the script support in 1.0a4 and discovered
* a few minor but troublesome problems with the interface. Here
* they are with some useful (I hope) suggested solutions:
*
* Problem: Script can only return "Content-Type:" and "Location:".
* Effect: Script cannot send an HTTP/1.0 header like "Content-Length",
* and it cannot report errors with HTTP/1.0 codes.
* Possible Solution(s): Allow the script to "take-over" header output,
* perhaps by detecting "HTTP/1.0 nnn" response string. Or have a
* configuration option that indicates a script wishes to do it all.
* Either way, you may want to provide the server indentification as
* an environment variable (SERVER_ID?) so that the script can do a proper
* Server: header. If the script can take over completely, it will
* need to know the protocol version (PROTOCOL environment variable?).
This is something Tony brought up, too, perhaps I'll make a new field to
tell the server to pass the header as-is. Env. variables with the server
name and protcol are a good idea.
* Problem: Script cannot return absolute URLs that reference itself.
* Effect: Script installation may require hardcoding information on
* how the server knows to run it (i.e., it knows it's called /htbin/foo).
* Possible Solution(s): Make all the script writers code in that
* information or provide an environment variable (SCRIPT_PATH?).
* The latter is preferable and allows the script to say things
* like "$SERVER_NAME$SCRIPT_PATH/go/here" when a relative URL
* is too cumbersome to emit.
Perhaps, then, a $SCRIPT_NAME env. variable? I call it name since it is a
translated name, not a path name.
* Problem: No way to distinguish "/htbin/prog?/foo" and "/htbin/prog/foo".
* Effect: User input could confuse the script.
* Possible Solution(s): Always force two script arguments when a search
* request has been detected so you get:
* URL #args args
* /htbin/prog 0
* /htbin/prog/foo 1 "/foo"
* /htbin/prog?foo 2 "" "foo"
* /htbin/prog/bar?foo 2 "/bar" "foo"
I wondered about this one myself. I chose the method I did because I wanted
to make the transition between the new and old interfaces a little less
painful.
* Problem: Cannot use Alias mechanism to point to a script.
* Effect: "Alias /foo /htbin/prog" gives you the script source of "prog"
* instead of running "prog".
* Possible Solution(s): Fix it in the code :-). I view this problem
* as pretty minor. A nice feature if the solution is simple.
Use ScriptAlias instead. That's what it's there for.
* Problem: Script has no way of knowing what server is running it.
* Effect: Hard to change script interface without breaking old scripts
* and servers. Also hard to write gateway scripts that are easily portable
* between different servers.
* Possible Solution(s): Drop in an environment variable like GATEWAY_PROTO.
* Script can key on that to figure out what the arguments mean, etc. No big
* deal now, but will make completely generic drop-into-your-server scripts
* easier to write.
I'm hoping to get a semi-ideal script interface into the official 1.0
release, and then not change it at all.
* No showstoppers here, but it would really be nice to be rid of the
* prog?foo" vs. "prog?/foo" ambiguity. The rest are liveable if
* inconvenient. Just say the word and I'll code up some fixes -- I'm
* quite eager to have the ability to publish some of my gateway code
* without having to publish my server along with it.
*/
Most likely, I will pursue these changes, and barring any other huge bugs,
the interface we come out with will be 1.0 and won't change.
--Rob