Re: Local program exection in WWW browsers
Date: Thu, 14 Apr 1994 14:58:07 --100
Message-id: <>
Precedence: bulk
To: Multiple recipients of list <>
Subject: Re: Local program exection in WWW browsers
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1570

It seems exec-ing local cgi programs is easiest if Mosaic (lynx?):

1. Reads the stdout of all external viewers and treats it as CGI output
2. Sends to the stdin of external viewers the results of the POST method
3. Doesn't copy local files to temporary files when invoking viewers - saves
   a split second and the viewer gets the actual path name of the local file.

This takes care of specific programs (e.g., now your gif "viewer" can return
html with an embedded <img> so xv/lview isn't needed, etc.).

To handle arbitrary programs, simply map files ending in ".cgi" or whatever
to application/x-cgi, then map that to "execsafeprog %s", as shown in NCSA's
executing shell scripts.  #3 above gives you the ability to check that the
program is local and is in WWW_EXECPATH (which you set in your .profile).

If #3 isn't done, the .cgi file could contain the name of a program to run.
Note that #2 is needed to support local form processing.  To avoid problems
with output from viewers, Mosaic could treat application/x-cgi as special.
Providing arguments could be done with file.cgi?-arg, etc.

>                           See 

> Briefly, it defines a new URL scheme "x-exec" which looks like:

> 	x-exec://program_name/some_args

> It looks to see that "program_name" is allowed by a WWW_EXECPATH
> environment variable and if so runs it as a CGI script with
> PATH_INFO set to "/some_args", etc.  and displays the output
> (which, of course, can be HTML, GIF, or any MIME-typed thing).