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 T Dengler <ro...@xades.com> on 2001/02/19 01:42:36 UTC

Clarification on Catalina TODO item: CGI emulation servlet

[apologies if this is a FAQ or misdirected; please let me know]

The Catalina TODO mentions an item under "Servlet Provided 
Functionality" which involves designing and implementing a CGI emulation 
servlet.

Where/To whom can I go for clarification on what the requirement is?  Is 
this something like a servlet which will run native programs in an 
environment conformant to CGI specs, exactly as a regular web server would?

Being a developer in real life, I would like to help out with any 
development needs.  I also wanted to start small, and this sounds like 
something that would be appropriate.

Chrs,
Martin


Re: Clarification on Catalina TODO item: CGI emulation servlet

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Martin T Dengler wrote:

> Craig R. McClanahan wrote:
>
> > That was exactly the original thinking -- create a servlet that would be able
> > to execute external applications in conformance with the CGI spec requirements
> > (principally related to environment variables, and connecting standard input
> > and output of the application program to the request and response streams
> > appropriately.
>
> Excellent.  I suppose the right thing to do now is propose a design to
> this list with specification references for review.  If that is too
> heavyweight I can just run the code by somebody (you, Craig?) after
> testing on my own Catalina build.
>

The details of offering code to be included are covered on the Jakarta web site

    http://jakarta.apache.org/site/getinvolved.html

but basically, you'll post the code itself (in a zip file or something) to the
TOMCAT-DEV list so that we can all look at it and comment.  Once the committers are
OK with it, one of us will check it in.

>
> > Having this functionality implemented as a servlet means that you can map it to
> > a directory path ("/cgi-bin/*") and/or a filename extension ("*.cgi"), in the
> > same way that you would do so in a web server.  Or, in a security conscious
> > environment, you could just remove the mappings to make CGI service
> > unavailable.
>
> Exactly, and I suppose the directory path w/could obviously be web
> app-specific, giving the normal encapsulation benefits.

It would pretty much have to be, because that's the only way your servlet would ever
get invoked.

>
> Would there be any scope for extra web-app-related information being
> available in the spawned-process' environment, so it (the CGI) could
> figure out the context path, etc.?
>

I would tend to start with all the standard CGI spec environment variables, so that
the CGI scripts you invoke can remain portable.  CGI doesn't really have the concept
of a "context path", but there are probably sufficient variables (like DOCUMENT_ROOT)
to accomplish what you would be after.

>
> > That would be great!  I will sign you up for that item.
>
> Thanks, I look forward to helping out; if I do something wrong please
> let me know.
>
> >
> > Craig McClanahan
> >
>
> Chrs,
> Martin
>

Craig



Re: Clarification on Catalina TODO item: CGI emulation servlet

Posted by Martin T Dengler <ro...@xades.com>.
Craig R. McClanahan wrote:

> That was exactly the original thinking -- create a servlet that would be able
> to execute external applications in conformance with the CGI spec requirements
> (principally related to environment variables, and connecting standard input
> and output of the application program to the request and response streams
> appropriately.

Excellent.  I suppose the right thing to do now is propose a design to 
this list with specification references for review.  If that is too 
heavyweight I can just run the code by somebody (you, Craig?) after 
testing on my own Catalina build.

> Having this functionality implemented as a servlet means that you can map it to
> a directory path ("/cgi-bin/*") and/or a filename extension ("*.cgi"), in the
> same way that you would do so in a web server.  Or, in a security conscious
> environment, you could just remove the mappings to make CGI service
> unavailable.

Exactly, and I suppose the directory path w/could obviously be web 
app-specific, giving the normal encapsulation benefits.
Would there be any scope for extra web-app-related information being 
available in the spawned-process' environment, so it (the CGI) could 
figure out the context path, etc.?


> That would be great!  I will sign you up for that item.

Thanks, I look forward to helping out; if I do something wrong please 
let me know.

> 
> Craig McClanahan
> 


Chrs,
Martin


Re: Clarification on Catalina TODO item: CGI emulation servlet

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Martin T Dengler wrote:

> [apologies if this is a FAQ or misdirected; please let me know]
>
> The Catalina TODO mentions an item under "Servlet Provided
> Functionality" which involves designing and implementing a CGI emulation
> servlet.
>
> Where/To whom can I go for clarification on what the requirement is?  Is
> this something like a servlet which will run native programs in an
> environment conformant to CGI specs, exactly as a regular web server would?
>

That was exactly the original thinking -- create a servlet that would be able
to execute external applications in conformance with the CGI spec requirements
(principally related to environment variables, and connecting standard input
and output of the application program to the request and response streams
appropriately.

Having this functionality implemented as a servlet means that you can map it to
a directory path ("/cgi-bin/*") and/or a filename extension ("*.cgi"), in the
same way that you would do so in a web server.  Or, in a security conscious
environment, you could just remove the mappings to make CGI service
unavailable.

>
> Being a developer in real life, I would like to help out with any
> development needs.  I also wanted to start small, and this sounds like
> something that would be appropriate.
>

That would be great!  I will sign you up for that item.

>
> Chrs,
> Martin
>

Craig McClanahan