I realize that others (everybody? :-) disagree with such a URL
scheme, but let me present my current mechanism for discussion.
If you're against it, then let your guiding principle in the
discussion be "If they're gonna do it, at least make them do
it as reasonably and safely as possible.".
Here's how it works. I have a new URL scheme called "x-exec".
A typical x-exec: URL looks like:
x-exec://program/all/the/rest
"program" is the name of the program to execute. The name is % escaped
so it may contain "/"s or other odd characters. The browser de-escapes
the name and then checks a compiled-in and an environment specified
list of directories. "program" must appear in one of the
directories or be listed explictly before it can be executed. If it
satisfies that test, "program" is run with "/all/the/rest" as a single
argument. The output of the program will look like an HTTP/1.0
response with status codes and MIME headers. A provision in the
browser to recognize raw HTML would be a nice but unnecessary feature.
There are a few things to note here. The default action of such
a patch will be to do nothing. Only if the installer puts something
on the internal list or if the user creates their list can anything
be executed. The list specification depends on the operating system.
On UNIX, an environment variable with colon-separated directories
(WWW_PATH? WWW_EXECPATH) is likely. DOS applications may choose a
similar option but with ";" as a separator. Program execution
must be done carefully -- use pipe(), fork() and exec() rather
than popen() or system().
My current implementation passes the rest of the URL as a single
argument. I recommend that the program be executed in the same
way as an external gateway script under NCSA's HTTPD -- the problems
both mechanisms face are extremely similar.
I hope we can hammer out the details on how this should be done,
if it must.