Re: launching executables through HTML files

Marc Andreessen (
Sun, 20 Jun 93 18:27:22 -0500

Tony Sanders writes:
> I think you should be able to configure the browser as to what MIME types
> it should handle and which get passed to an external program. Something
> like the following (for X applications anyway):
> XMosaic*contentTranslations: \
> #override \n\
> text/html: text_html() \n\
> text/*: text_plain() \n\
> image/gif: image_gif() \n\
> image/jpg: image_jpg() \n\
> image/*: exec(xv) \n\
> video/mpg: exec(mpeg_play -loop) \n\
> audio/*: exec(audio_play) \n\
> exec/*: verify_exec() exec(exec_handler)\n\
> */*: unknown()
> The #override means replace the translation table completely,
> otherwise do a merge.

The reason I've held off doing that in general, believe it or not, is
because I'm not sure what method to use. I'd rather not invent a new
method. I may use mailcaps (RFC 1343). ?

> Can anyone see that having a URL "exec:..." is better than simply
> groking "content-type: exec/*"? I think using content-type is
> better because the "....:" part of a URL should specify how to
> retrive the data, not what to do with it.

Except that one thing you're never going to do (at least, that I'm
never going to want to let you do :-) is to actually retrieve
executables over the net. If you look at it from the point of view
that the access method of a URL describes the process to be used to
fetch data, then you could say that could be (a) a network protocol or
(b) a local executable, without violating the metaphor.

I dunno... I still don't like the idea of firing off arbitrary
executables on the client side, so I'm not gonna strenuously argue
either way.

I take it by your use of the exec/* content type that the command to
be executed would be in the data part of the message element and not
in the subtype field of the content type, though, right?