Re: Annoucement: Local Browser Execution

Axel Belinfante <>
Message-id: <>
Subject: Re: Annoucement: Local Browser Execution 
In-reply-to: Your message of "Wed, 15 Dec 1993 08:03:46 -0500."
From: Axel Belinfante <>
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
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.. :-)


In message <> (Henning G. Schulzrinne) writes:
> > From research!!www-talk-request Wed Dec 15 05:16:12 1993
> > To:
> > 
> > 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
> > "".  That is, build *into your client* the
> > special case that if you see " 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.

<>   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