You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Martin Dengler <ro...@xades.com> on 2001/04/01 01:14:52 UTC
CGI support servlet (TC 4) -- feedback wanted
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?
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?
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...
2) Addition to default context
Would this CGI servlet be added to the default context similar to
SsiInvokerServlet? 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?
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...
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?
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?
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)?
Thanks in advance for feedback/suggestions.
Chrs,
Martin
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Martin Dengler <ro...@xades.com>.
Amy,
Thanks for the feedback -- I have not been able to finish my changes
but will take advantage of the upcoming weekend and look forward to
getting something together for tester.
Martin
Amy Roh wrote:
>> Right now they are basically the same scripts that I added to the
>> examples webapp. So, should I just duplicate the scripts so we have one
>> set in <tomcat-root>/webapps/examples/WEB-INF/cgi-bin and one set in
>> <tomcat-root>/tester/src/bin? Or would the tester/src/bin/tester.xml
>> simply have some targets which tested the output of some requests to
>> http://server/examples/cgi-bin/cgitester.cgi, etc.?
>>
>
>
> I think once the feature is fully implemented, we can work on a tester which tests
> your scripts and add it to our set of tests. So whenever the tester is ran, we can
> display something like "CGI tests all PASSED" following the current tester style.
>
>
[snip]
>>
>> I have made some more updates which I have not posted yet. Once I take
>> into account your & others' suggestions, I will update that zip file. I
>> imagine I can make most of the changes tonight and re-package tomorrow,
>> so hopefully a new one will be up soon.
>>
>
>
> Awesome. Thanks!
>
> Cheers,
>
> Amy
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Amy Roh <am...@apache.org>.
> Right now they are basically the same scripts that I added to the
> examples webapp. So, should I just duplicate the scripts so we have one
> set in <tomcat-root>/webapps/examples/WEB-INF/cgi-bin and one set in
> <tomcat-root>/tester/src/bin? Or would the tester/src/bin/tester.xml
> simply have some targets which tested the output of some requests to
> http://server/examples/cgi-bin/cgitester.cgi, etc.?
>
I think once the feature is fully implemented, we can work on a tester which tests
your scripts and add it to our set of tests. So whenever the tester is ran, we can
display something like "CGI tests all PASSED" following the current tester style.
>
> >
> >> 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
> >
>
> Cool.
>
> >> 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.
>
> Yes, on a per-webapp level?
>
I meant like an absolute directory like "cgi-bin" directory in file system. But
there're options....
>
> >
> > Is the source code from http://www.martindengler.com/proj/CGIGatewayServlet.zip
> > the most updated one?
> >
>
> I have made some more updates which I have not posted yet. Once I take
> into account your & others' suggestions, I will update that zip file. I
> imagine I can make most of the changes tonight and re-package tomorrow,
> so hopefully a new one will be up soon.
>
Awesome. Thanks!
Cheers,
Amy
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by martin <ro...@xades.com>.
Amy,
Thanks for the feedback; see comments inline.
Martin
Amy Roh wrote:
> Hi Martin,
>
> See comments below.
>
> Martin Dengler wrote:
>
[snip]
>>> 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.
>>
>>
Cool, I will include that as part of my submission.
>
>> 4) 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?
Right now they are basically the same scripts that I added to the
examples webapp. So, should I just duplicate the scripts so we have one
set in <tomcat-root>/webapps/examples/WEB-INF/cgi-bin and one set in
<tomcat-root>/tester/src/bin? Or would the tester/src/bin/tester.xml
simply have some targets which tested the output of some requests to
http://server/examples/cgi-bin/cgitester.cgi, etc.?
>
>> 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
>
Cool.
>> 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.
Yes, on a per-webapp level?
>
> Is the source code from http://www.martindengler.com/proj/CGIGatewayServlet.zip
> the most updated one?
>
I have made some more updates which I have not posted yet. Once I take
into account your & others' suggestions, I will update that zip file. I
imagine I can make most of the changes tonight and re-package tomorrow,
so hopefully a new one will be up soon.
>
> Amy
>
>
Thanks for all the feedback.
Martin
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Craig R. McClanahan" wrote:
>
> On Mon, 2 Apr 2001, Amy Roh wrote:
>
> > Hi Martin,
> >
> > See comments below.
> >
> > Martin Dengler wrote:
> > >
> > > 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.
>
I agree that SSI and CGI should not be enabled by default.
Setting security policies for use by the SecurityManager is based on
the codebase (jar file) the class is loaded from. Catalina and Jasper
need more permissions than a web application. To enable the ability
for fine grained security policies servlets would need to be packaged
in their own jar files. I can see having webdav, ssi, cgi, and manager
servlets broken out with each one having their own jar file so different
security policies can be set for each servlet.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by martin <ro...@xades.com>.
Mel Martinez wrote:
> --- Bip Thelin <bi...@razorfish.com> wrote:
>
[snip]
>>
>> +1 on having CGI in web.xml but commented out,
>> regarding SSI I suggest
>> we add a configure property(like Apaches NoExec)
>> that set's whether #exec is
>> allowed or not. And if that property is not set it
>> defaults to NoExec.
>>
>> So for a standard setup SSI would be allowed but
>> you'd have to bug your
>> Tomcat sysadmin to have the #exec option enabled.
>> Sort of like a standard Apache setup.
>>
>> ..bip
>
>
> +1 on what Bip said.
Cool -- regardless of the security manager settings we decide on, I will
submit with the web.xml entry commented out as requested.
>
> mel
>
Chrs,
Martin
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Mel Martinez <me...@yahoo.com>.
--- Bip Thelin <bi...@razorfish.com> wrote:
> "Craig R. McClanahan" wrote:
> >
> > > >
> > > > 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.
>
> +1 on having CGI in web.xml but commented out,
> regarding SSI I suggest
> we add a configure property(like Apaches NoExec)
> that set's whether #exec is
> allowed or not. And if that property is not set it
> defaults to NoExec.
>
> So for a standard setup SSI would be allowed but
> you'd have to bug your
> Tomcat sysadmin to have the #exec option enabled.
> Sort of like a standard Apache setup.
>
> ..bip
+1 on what Bip said.
mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Bip Thelin <bi...@razorfish.com>.
"Craig R. McClanahan" wrote:
>
> > >
> > > 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.
+1 on having CGI in web.xml but commented out, regarding SSI I suggest
we add a configure property(like Apaches NoExec) that set's whether #exec is
allowed or not. And if that property is not set it defaults to NoExec.
So for a standard setup SSI would be allowed but you'd have to bug your
Tomcat sysadmin to have the #exec option enabled.
Sort of like a standard Apache setup.
..bip
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by martin <ro...@xades.com>.
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
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
Re: CGI support servlet (TC 4) -- feedback wanted
Posted by Amy Roh <am...@eng.sun.com>.
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.
>
> 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. :-)
>
> 2) Addition to default context
>
> Would this CGI servlet be added to the default context similar to
> SsiInvokerServlet?
Yes.
> 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?
>
> 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
>
>
> 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