Re: Annoucement: Local Browser Execution

Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Message-id: <9312151414.AA18443@utis179.cs.utwente.nl>
To: www-talk@nxoc01.cern.ch
Subject: Re: Annoucement: Local Browser Execution 
In-reply-to: Your message of "Wed, 15 Dec 1993 08:03:46 -0500."
             <9312151304.AA13944@dxmint.cern.ch> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Organisation: University of Twente, Dept of Informatics,
              Tele Informatics Group, PO Box 217,
              NL-7500 AE Enschede, The Netherlands
Phone: +31 53 893774
Telefax: +31 53 333815
Date: Wed, 15 Dec 93 15:14:23 +0100
Sender: belinfan@cs.utwente.nl

Inspired by all this I'm trying to do something similar - using what is
available right now, without hacking the client.

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 <9312151304.AA13944@dxmint.cern.ch> 
hgs@research.att.com (Henning G. Schulzrinne) writes:
> > From research!dxcern.cern.ch!www-talk-request Wed Dec 15 05:16:12 1993
> > To: phillips@cs.ubc.ca
> > 
> > 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.

<Axel.Belinfante@cs.utwente.nl>   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