httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Suggestion: Associate file types with processors for CGI (fwd)
Date Wed, 13 Sep 1995 15:07:03 GMT

This sounds like it might be worthwhile..

Ack already sent.

Forwarded message:
> From  Tue Sep 12 19:04:10 1995
> From:
> Message-Id: <>
> Date: Tue, 12 Sep 95 22:03:52
> To: <>
> Subject: Suggestion: Associate file types with processors for CGI
> X-Mailer: IBM WebExplorer DLL 
> Although it has been barely possible to assume that the filename in a CGI
> request is directly execable, this is becoming more difficult to support.
> mod_cgi.c:
>     if((!r->args) || (!r->args[0]) || (ind(r->args,'=') >= 0)) 
>         execle(r->filename, argv0, NULL, env);
>     else 
>         execve(r->filename, create_argv(r->pool, argv0, r->args), env);
> This is certainly classic "httpd", but it is inefficient in Unix, problematical
> in other systems (NT and OS/2) and excludes languages that are byte-compiled
> instead of source (mainly java).  The heavy use of Perl in CGI programming
> can tolerate this because you can "#! usr/local/bin/perl" at the start of the file.
> However, it is more efficient if *.pl is directed to perl at the exec, if *.rexx is
> directed to rexx (Regina), and it is necessary for *.class to be an argument 
> to "java" because the class files are not source and yet are not direcly 
> executable.  More generally, it would be nice if there was a table of CGI file
> extensions and the processors that should be called to execute them.
> Yes I know about the "/cgi-bin/java?InterestingStuff.class" hack, but it 
> requires that the "java" executable be in the /cgi-bin directory and I have
> had great difficultly making it work if it is not left over in the the /java/bin/
> tree.  Furthermore this is an ugly URI and tends to produce results that are
> not portable across different systems.
> If the extension of r->filename is found in the types table, then the 
> execxx should call the associated processing module and r->filename should
> be passed as the argument.
> If I believed that this was a special local situation, then I would just make the
> change as a module for my own purposes.  However, this is a problem that lots
> of people struggle with (though more often on non-Unix ports) and it makes
> sense to lay it on the table.  If the HotJava browser becomes more widely used, 
> and if Java Applets are supported by Netscape, it will only be a matter of time
> before people run up against the problem of supporting Java CGI.

View raw message