Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 6/20/14, 6:19 PM, André Warnier wrote:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Rahul,
On 6/20/14, 3:10 PM, Rahul R wrote:
This is from my conf/web.xml
<servlet> <servlet-name>cgi</servlet-name>
<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
<init-param>
<param-name>debug</param-name> <param-value>0</param-value>
</init-param> <init-param>
<param-name>cgiPathPrefix</param-name>
<param-value>WEB-INF/cgi</param-value> </init-param>
<init-param> <param-name>passShellEnvironment</param-name>
<param-value>true</param-value> </init-param> <init-param>
<param-name>executable</param-name>
<param-value>perl</param-value> </init-param>
<load-on-startup>5</load-on-startup> </servlet>
<servlet-mapping> <servlet-name>cgi</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern> </servlet-mapping>
Please let me know what do you mean by privileged usage.
https://tomcat.apache.org/tomcat-7.0-doc/cgi-howto.html
Since you have mapped the CGIServlet to /cgi-bin, then you will
want to have your HTML file (located in the webapp root) to
reference "/cgi-bin/read_toggle.cgi" as the action.
Note that the URL reference is mapped from the URL space
(/cgi-bin/read_toggle.cgi) into the webapp's resource space
(WEB-INF/cgi/read_toggle.cgi) which is why the paths don't appear
to match.
Finally, if the Perl script isn't that complicated, you should
consider re-writing it in Java since you are using a Java
application server. It will be much easier to deal with
everything that way.
Who said that the cgi-bin script was perl ?
The OP. Look up in the configuration: the "executable" is set to
"perl".
That's just the default, as it comes in the standard Tomcat distribution. See also
https://tomcat.apache.org/tomcat-7.0-doc/cgi-howto.html#Configuration
The OP never actually said what the script was.
Which is a reason why I raised the question.
(perl may not even be installed on that system; but since so far Tomcat did not even
trigger the CGI servlet, we are not yet at the point where this would show up.)
I suppose he could be using a tcl/tk binary re-named to "perl"
just to have a laugh, but probably not.
He could also be using a stand-alone Java application as a cgi-bin script, for
all we know..
Wouldn't that be interesting ? Would the JVM which runs Tomcat actually be smart enough
to notice this, and not load and run another JVM then ?
(not saying that it isn't, but nobody said it was either). As it
stands, whatever it is, it is being run (at first) by perl. But if
perl notice another interpreter in the shebang line, it will
happily cede its turn.
Fair enough. I've seen some stupid things in my time, but having Perl
hand-off to some other binary just seems wasteful.
It is. Tomcat runs the CGI servlet (actually, a Java JVM does that); the CGI servlet sets
up a complete CGI environment (variables and all), then asks the JVM to load and run a
perl interpreter (and the JVM probably asks the underlying OS to do that). The perl
interpreter loads, reads the cgi script, sees the shebang line, and exec's a shell to run
the script. Then the shell reads and runs the script. And the same at each invocation.
If one is looking for a small footprint and/or performance, that's not exactly
the way to go.
I was basically raising the question, because it seems to me that, if the OP actually read
the page https://tomcat.apache.org/tomcat-7.0-doc/cgi-howto.html, it nevertheless does not
seem that he read it very carefully. So the fact that perl is the default executable may
have escaped his attention. And since perl will call a shell to run the script if this
actually is a shell script with a proper shebang line, he may never notice all the above.
And then wonder why this appears so resource-intensive.
Anyway, it raises the fundamental question of why go though all
the trouble to run a (possibly perl) cgi-bin script within Tomcat
?
+1
(Also @David) :
Let's face it : Tomcat is not particularly optimised to run cgi-bin scripts, be they perl
or otherwise. There are better tools to do this, such as an Apache httpd front-end which
the OP seems to have been using so far.
In this particular case, I believe it would probably be better to keep the configuration
maybe a bit more complex, but probably more efficient.
There are cases where simpler is not necessarily better, and I felt that it was worthwhile
pointing this out.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
