In my _server_ i have a mapping from
http://host:port/exec/blah blah
into a HTTP/1.0 MIME document of type: application/x-exec with contents
blah blah
Probably the document should also contain some information about the
document BASE.
In my .mailcap i have a mapping:
application/x-exec; x_exec %s
The x_exec program is what i'm currently working on. It should execute
the commands in the file it receives, but not blindly: it should check
whether the commands are considered 'safe' (eg. by checking if they are
in a directory that contains (links to) the 'safe' commands), and it
should probably filter out shell meta-symbols to avoid trickery
(or maybe we can handle this in a different way).
It should catch the standard output of the commands in a (tmp)file, and
be ready to give this file to Mosaic via the remote control feature.
This is where the information about the document BASE will be needed:
the stdout of the command is supposed to be HTML, which might contain
relative links. I think that the Mosaic feature recently added to
handle mailed documents will solve/handle this.
One remaing problem: how/when do we remove the tmp-file that contains
the standard output?
What do people think? Could this be made to work? I'll try anyway.. :-)
Regards,
Axel.
In message <[email protected]>
[email protected] (Henning G. Schulzrinne) writes:
> > From research!dxcern.cern.ch!www-talk-request Wed Dec 15 05:16:12 1993
> > To: [email protected]
> >
> > I think x-exec: is an ugly hack. I'm about to propose something that
> > at first glance looks like an uglier hack, but maybe after you think
> > about it for a bit you won't shoot me:
> >
> > Right now, you're taking something 'x-exec:blah blah' and treating it
> > as a URL that executes something special.
> >
> > Why not, instead of searching for "x-exec:", search for
> > "http://cs.ubc.ca/exec/". That is, build *into your client* the
> > special case that if you see "http://cs.ucb.ca/exec/blah blah",
> > instead of sending http protocol somewhere, you execute "blah blah" as
> > a shell command.
>
> I believe this solution to be far superior. One of the nicer things
> about URLs is that you don't necessarily know or care whether something
> returned to you has been generated dynamically or exists as a file.
> Conceptually, both are the same: In either case, you provide a
> string that maps into some output, to be returned. For file retrieval,
> the mapping is done by the filesystem, for a shell command it is done
> by some special program. You might even decide to switch between the
> two, e.g., if the range of arguments provided is small enough that
> they can easily be mapped into files.
<[email protected]> tel. +31 53 893774 fax. +31 53 333815
University of Twente, Tele-Informatics & Open Systems Group
P.O. Box 217 NL-7500 AE Enschede The Netherlands
"ili ne sciis ke estas neebla do ili simple faris" -- Loesje