On Mon, 2 Apr 2001, Amy Roh wrote:
> Hi Martin,
>
> See comments below.
>
> Martin Dengler wrote:
>
> > I am putting together the next round of updates to the CGIGatewayServlet
> > which provides CGI capabilities (especially if you map it to /cgi-bin/* :)).
> >
> > Hopefully this will take it to full beta-level; I would like to get it
> > to a point where it can be included in CVS & the next beta of Tomcat 4.0.
> >
> > A couple of issues have arisen and I would like to solicit opinions on:
> >
> > 1) Name, Package, and Inner Classes
> > 2) Providing Functional testing classes
> > 3) Providing Examples
> > 4) Addition to default context
> > 5) Default location of cgi scripts
> >
> > This is my first attempt at wide feedback/partipation, so please let me
> > know any meta-comments, definitely. (For example, is this off-topic, too
> > much detail, etc.?)
> >
> > Issues:
> >
> > 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.
> >
> > Package: Right now I have put this code in one source file in the
> > org.apache.catalina.servlets package. I believe this to be the right
> > package based on WebDav, SsiInvoker, and other similar servlets. Any
> > suggestions?
>
> I think the invoker servlet is in the right place
> (org.apache.catalina.servlets).
>
> >
> >
> > Inner Classes: The CGIGatewayServlet.java file has one main class and
> > two inner classes. Do we have any design-type preferences or lack
> > thereof vis-a-vis inner classes? The inner classes could be moved out
> > to org.apache.catalina.util as a thought. My personal inclination would
> > be to leave them as inner classes, since they are not particularly
> > applicable to other parts of catalina. However, that could be viewed as
> > slightly detracting from their maintainability...
> >
>
> 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.
> >
> > 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.
> > If so, would people prefer I do that myself and
> > submit a load of file patches for the commit of the CGI servlet &
> > related files which included the catalina web.xml?
>
> This is a minor issue adding a few lines to catalina web.xml. I have done this
> already on my CVS tree.
>
> >
> >
> > 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.
> >
> > 3) Providing Functional testing classes
> >
> > I was wondering if and how I should add any testing cgi scripts. I have
> > some (obviously :)), but should they be put into the tester area because
> > they are for testing, or should I reuse some examples webapp (above
> > issue #2) cgi scripts? Any issues with this dependency?
> >
>
> We can put them into tester area so we can run tester if/when we
> add/modify CGI feature. Could you send me these scripts as well?
>
> >
> > 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"?
> >
> >
> > Issue 2) if people like it, should we make it the default setting (by
> > defining an init-parameter for the CGI servlet in the container-wide
> > web.xml file)?
>
> I think we should designate a cgi directory where people can put CGI scripts for
> security reasons.
>
> Is the source code from http://www.martindengler.com/proj/CGIGatewayServlet.zip
> the most updated one?
>
> Cheer,
>
> Amy
>
> >
> >
> > Thanks in advance for feedback/suggestions.
> >
> > Chrs,
> > Martin
>
>
Craig
