Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <3ACAC0E9.5030103@martindengler.com>
Date: Wed, 04 Apr 2001 07:36:25 +0100
From: martin <root@xades.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 0.8.1) Gecko/20010323
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: CGI support servlet (TC 4) -- feedback wanted
References: <Pine.BSF.4.21.0104021421290.44472-100000@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Craig R. McClanahan wrote:

> 
> On Mon, 2 Apr 2001, Amy Roh wrote:
> 
> 
>> Hi Martin,
>> 
>> See comments below.
>> 
>> Martin Dengler wrote:
>> 
>> 


[snip]


>>> 1) Name, Package, and Inner Classes:
>>> 
>>> Name:  Current name is CGIGatewayServlet.  The rationale is "this is the
>>> first name I thought of."  Would we prefer CGIInvokerServlet?
>>> 
>> 
>> I personally prefer CGIInvokerServlet than CGIGatewayServlet since
>> CGIGatewayServlet sounds kind of redundant (because it is CGI(Common Gateway
>> Interface) GatewayServlet.  This doesn't matter much though.
>> 
> 
> 
> I would be just as happy with CGIServlet (and SSIServlet for that
> matter).  But org.apache.catalina.servlets is definitely the right
> package.
> 

Agreed with these and other comments I received on the redundancy point. 
  Both CGIServlet and CGIInvokerServlet sound good to me.  I can change 
it to CGIServlet and see how that works.

[snip]


>>> 
>>> Inner Classes:  The CGIGatewayServlet.java file has one main class and
[...]
>> 
>> BIG +1 for separating those inner classes and putting them in
>> org.apache.catalina.util.cgi.  It will be a LOT easier to maintain.  I did this
>> already for myself to review your code.  I can send them to you if you want to
>> save a little time.  :-)
>> 
> 
> 
> +0 -- I'm not hung up on inner classes, but do not have any problem if
> others want them separated.
> 

Hmm, yeah I thought people might generally find it slightly preferable. 
I'm generally +0, but sounds like it would be useful.

I will probably leave it a couple more days before I bring them out, 
just to get the various class responsibilities bedded down.  Especially 
the exec functionality (Bip and I are getting together on this for both 
SSI/CGI) would be reusable or at least easiest maintained outside as its 
own class(es).


> 
>>> 2) Addition to default context
>>> 
>>> Would this CGI servlet be added to the default context similar to
>>> SsiInvokerServlet?
>> 
>> Yes.
>> 
> 
> 
> I would suggest that we do this, but leave it commented out.  The reason
> is that the potential for mischief is *much* larger when we are talking
> about executing outside programs instead of just displaying content back
> to a web browser.  I vote for making the Tomcat sysadmin have to enable
> this feature explicitly if they want it.
> 
> Once we implement the #exec functionality in SSI, the same argument would
> apply here -- unless we added a config option to disable the #exec by
> default but left everything else alone.
> 
> An alternative (possibly additional) approach would be to tweak the
> security manager properties so that executing external programs is *not*
> allowed by default.  That way, we could leave these two servlets defined
> in the conf/web.xml file, but they won't be able to cause damage.


+1 on both counts.  Does that imply that for out-of-the-box Tomcat, 
maybe some CGI examples wouldn't work?  That's certainly not a bad 
thing, but it brings a couple of additional ideas to mind:
1) we leave the servlet in catalina's web.xml commented out and the 
security manager restrictive as suggested; or
2) As #1 above but also include the servlet definition & mapping in the 
examples webapp's web.xml, with the servlet smart enough to display a 
useful message if the security manager restricts access.  That way the 
servlet examples would produce meaningful behavior out-of-the-box, but 
the security restriction on running outside programs is still in place. 
  The admin would have to explicitly enable any such wild-and-crazy 
functionality.


>>> 
>>> 3) Providing Examples
>>> 
>>> Would it be appropriate to provide some links in the examples webapp
>>> along with an example cgi script?  I would have thought so...
>> 
>> YES.  In fact, could you send me some?
>> 
> 
> 
> Of course, such things are going to be platform-specific ... be sure to
> include examples for Windows as well as Unix platforms.
> 

Good point, I guess I should provide:
1) Unix shell example (using #!/bin/sh)
2) Windows batch (*.bat)
3) Unix perl (using #!/usr/local/bin/perl, assume perl 4 only)
4) Windows perl (*.pl; would this alone work though??)


>>> 5) Default location of cgi scripts
>>> 
>>> In another project, we have put all cgi scripts under
>>> <webapp>/WEB-INF/cgi since they are then 1) not liable to be served by
>>> the container; yet 2) still encapsulated underneath the webapp's own
>>> directory structure.
>>> 
>>> One observation and two issues here:
>>> 
>>> Observation: the Servlet spec is obviously silent on CGI placement
>>> issues; yet we should probably support (and even default to?) something
>>> congruent with standard CGI practice of separating the HTML and CGI
>>> scripts (/doc-root and /cgi-bin) while not encouraging anything which
>>> breaks the Servlet API's web application filesystem (or war file)
>>> boundaries.
>>> 
>>> Issue 1) generally, how do people like the <webapp>/WEB-INF/cgi solution
>>> in light of the above observation?
>> 
>> +1
>> 
> 
> 
> One thing to keep in mind is that this won't work if the webapp is run
> directly from a WAR file unless you go to interesting lengths to extract
> these scripts from the WAR somehow.
> 
> I think it should also be possible to configure an absolute disk directory
> as the place where CGI scripts are executed from.
> 
> For consistency with Apache, perhaps the default directory name should be
> "cgi-bin" instead of "cgi"?
> 

+1 to the name "cgi-bin" rather than "cgi". I will make that change.


Good point regarding the cgi's presence (or lack thereof) in the file 
system; I would ideally like to support all three cases: 1) CGI in 
absolute directory; 2) CGI in file system below <webapp-root>; and 3) 
CGI in WAR (obviously also below <webapp-root>).

I guess a proposal along those lines would go:

1) If the servlet's cgi directory InitParameter (currently 
"cgiPathPrefix") is specified in absolute form, then simply use that 
absolute path;

2) otherwise if the prefix is specified in relative form and there is a 
file-system representation of the <webapp-root>/<cgiPathPrefix> 
directory, use that (the CGI spec, though explicitly stating CGIs need 
not have a file system representation, does define a number of rules for 
running CGIs which would only be applicable if the CGI is in a specific 
file system directory);

3) otherwise if the prefix is specified in relative form and there is NO 
file-system representation (as you said, never guaranteed by the Servlet 
spec to be present), use getResource() (possibly getResourceAsStream()) 
to load the cgi, write it out to File.tempDir() maybe, and execute it there.

The above sounds a little bit much on review...any thoughts?

> 
> Craig
>

Thanks for all the feedback...

Chrs,
Martin