Re: [OT] Issue with cgi/perl webpage

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Neven,

On 11/20/13, 11:48 AM, Neven Cvetkovic wrote:
> Ultimately, CGI is a very old technology that had its own share of 
> performance (and security) problems. Usually, CGI scripts were
> replaced with superior Java Servlet technology (or some other
> better technology) and hence the need for Tomcat application server
> (servlet container). Hopefully, the rest of the mailing list
> members share my sentiments about the CGI :)

- -0

The only thing that really makes CGI "outdated" is that CGI itself
didn't have an API... or if you could call it an API, it was very
basic. It basically said "you get the query string in a big blob and
you can read standard input if you want to get the entity body". Then
everyone set to work writing their own custom parsing routines. I
remember copy/pasting stuff in Perl way back in 1994 and now having
any idea what the code actually did.

These days, you can pretty much write a Perl script and say "use CGI;"
and it's just magic, safe, etc. CGI has come a long way.

The last remaining problem is really that of performance: the CGI
model launches a new process for each request (even though you can
cheat a bit using things like mod_perl, etc.) and so there is a
performance hit right there. If you want to keep information between
requests, you have no choice but to write it to some form of
non-volatile storage (as far as the "application" is concerned).
RDBMS, flat file, etc.

More recent systems (I hesitate to say "modern" because it implies
that they are better simply because they are newer, and that the older
methodologies are simply worse by definition) are supported by much
more complicated software, APIs, etc.

Note that container-based systems like Tomcat have their own
performance problems: they have to manage all the stuff that they are
... well, required to support. If you peel-away all of the stuff that
Apache httpd provides *aside* from the Common Gateway Interface, you
are left with a server that primarily pumps bytes back and forth
between the client and the script. Tomcat has all kinds of moving
parts that make it possible to do nice things, but those moving parts
have a cost.

(It's worth noting that I believe such costs are worth it. That's why
I live in the container-based world instead of writing Perl- or
PHP-based applications.)

Want to deploy a single "Hello, World!" CGI script? No problem. Just
drop "#!/bin/sh\n\necho "Hello, World!" into a .cgi file in your
document root and tell Apache httpd it's okay to run it.

Want to deploy a single "Hello, World!" script on Tomcat? Well, first
you have to know where the auto-deployment directory is (hint: it's
not a document root), and then you have to create a directory in
there, and then drop a .jsp file in there. The good news is that
"Hello, World!" is a valid JSP file without any of the fluff you need
to make a shell script run. But the small amount of orientation
required just to get the point of dropping text into a file can be
confusing.

Once the almighty "container" is involved, there is pressure to make
it do more things. Sessions. Replication. Websockets. These are all
very good and very useful things, but it further complicates the
scenario. It's just a tough world to jump into with little to no planning.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSjrUUAAoJEBzwKT+lPKRYdcsQAIWqzHUbSimrUmXcYw9KH0zs
fkZCQvi3Hqon1afyun6fU+NT8Ta0YkOYKW8gEiWvrogcZtMl1Q/oxOKSWZvPG8g1
8nPyDbACRL2715VUKuWgCTfABuQnHYOjFuakqAfZsXcVigxfpwWyw8eS7KfwpaDv
vr/ZwqDv2ThQs63rk2rO5HW9o65nk2+XX4RBaUAw6lRZ7AfKMH5upR5Qwe231aKR
DBF6GsuoWGeyONPXyGGIcrjLeizg1pOf1m0W3cTTIgI6UBNFUez+hZHGpFxbkrNE
FX3onEVfrjlaxfSFmDx4ytDyOo973fhMALrasvIUSPqdKhjvIFHTYarZHRrOxex1
/L+YWnth7xAWTHPz+SzM7YWzRTDfWeOMq9PCx8wdoV88BJ35tQerxowdvbo+fPJN
S+Y+zw2iZwlyN8bVfwVpG81my8SEtFgrxhyPZMTqDK8RppL1QlC+aemQHiafTwoH
78+JP1HRR/tgYM9WXsDmOhIFgZp2pjATvuklqc5gw7BWX6J9UF8LjqEAmgwj5/KI
JlcMgCLH91WvjU/7p0jFnTMGHalL8Bz4L4KFp9OwA4gwkvjZQF1q1MbEGU/GVHP+
z2hJHeC4ugXk9zzO9imlUMZhC/pNGkwc/5leSMaHhwd0uZMatKh3sM4LLmoptiDP
0/kSWWI/zKK0USODk240
=21G3
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Issue with cgi/perl webpage

[André Warnier <aw...@ice-sa.com>]

Felipe wrote:
> Interesting, so do container-based systems such as Tomcat rely heavely on
> httpd? 

Not necessarily. Read on.

I've read that many people use Tomcat just for webapp deployment and
> use apache to handle static pages, among other things, but is it reasonable
> to use Tomcat to handle static pages, or is it solely for webapp server?

By design, Tomcat is primarily a "java servlet container", meaning that its primary design 
goal is to provide an environment to run java servlets efficiently.

But it is rarely so that applications would consist only of java servlets, so there exists 
also within Tomcat a "default servlet", which is invoked by Tomcat to serve any request 
which cannot clearly be assigned to any other servlet, and which consequently does serves 
most static content (html pages, stylesheets, images, ..).

And it just so happens that this default servlet is very efficient too, so that in the end 
Tomcat can perfectly be used as a "generic webserver" to serve both static content, along 
with the results of servlets execution.

There also exists a "cgi-bin servlet" which can run cgi-bin scripts and programs.
But this cgi-bin servlet is not really optimised for any particular kind of cgi-bin 
programs/scripts, and that is where other webservers may "beat tomcat" in terms of efficiency.

For example, if you are talking about cgi-bin scripts written in Perl or PHP : there exist 
special add-on modules for the Apache httpd webserver, which can optimise the running of 
scripts written in such languages (usually by pre-compiling them and keeping the compiled 
version in some cache memory)(*).  Such add-on modules do not exist for tomcat, and thus 
if a main part of an application would consist of such scripts, it would be more efficient 
in an overall sense to use a front-end webserver like Apache httpd, to run these parts of 
the application, and then have Apache httpd "delegate" to a tomcat back-end what is 
destined for java servlets.

When you reflect about this, it is exactly the same in reverse : Apache httpd could also 
run cgi-bin scripts written in Java.  It would just have to start a JVM at each 
invocation, to compile and run the java script.
Of course, that would be very inefficient, which is why for running java servlets it is 
better to use tomcat (or another java servlet container).

There is nothing /in the principle/ that would prevent someone from writing a special java 
"perl cgi-bin servlet" for tomcat, which would duplicate the functionality of some of what 
the mod_perl module does for Apache httpd, and make it very efficient to run perl cgi-bin 
scripts under tomcat (**).
It just hasn't been done yet, the main reason being probably : why do it ? (when it is 
easy to configure Apache httpd as a front-end to tomcat, and do it there using mod_perl).

(*) See http://perl.apache.org
(**) and similarly, one could think about a "mod_java" add-on module for Apache httpd

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Issue with cgi/perl webpage

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Felipe,

On 11/22/13, 10:29 AM, Felipe wrote:
> Interesting, so do container-based systems such as Tomcat rely
> heavely on httpd?

No, but it's quite common to see httpd used to "front" a Tomcat-based
application. This is a good strategy when you need complicated
deployments with different JVMs running different applications (or
maybe just multiple JVMs running the same application, for fail-over
and load-balancing).

> I've read that many people use Tomcat just for webapp deployment
> and use apache to handle static pages, among other things, but is
> it reasonable to use Tomcat to handle static pages, or is it solely
> for webapp server?

Tomcat does a great job as a static web server, but to get better
performance from the default you should:

1. Enable APR (connectors will auto-detect and use) if you use HTTPS

or

2. Switch to the NIO connector if you don't use HTTPS

APR's OpenSSL-based TLS implementation turns out to be faster than
other combinations of code. NIO and APR are about evenly-matched when
it comes to throughput and scalability, though I would bet on NIO all
other things being equal.

> I'm actually interested in using Tomcat for a personal project. It
> is using an Arduino Uno microcontroller (an AVR microcoontroller,
> specifically Atmel's ATMEGA 328), I would like to use the arduino
> as a server that could handle requests by way of a web interface
> control panel. I think this is would be an appropiate scenario to
> use JSP and Tomcat.

A JVM will not likely be a great choice on that platform. Modest
processor and low memory? Sounds like a disaster for a server-quality
JVM. You could look at an embedded JVM, but running Tomcat on top of
that isn't likely to pay off.

> Initially I would create a simple webapp that has prompt (where a
> user can input a command that the arduino will then act on) and
> display analog reading's (so as to monitor).

This kind of thing can be done with a simple Bash script, and use a
lot less memory. Be aware that what you are doing is (intentionally)
opening a huge security hole in your setup.

> I'm just no sure how to go about hosting tomcat, I'm pretty sure it
> is not possible to run on the arduino, but maybe using port
> forwarding or web socket to have Tomcat on a laptop or maybe a
> rasberry pi. Would this be a feasible method?

Probably not. If you were going to do all that, what's the point in
running Tomcat at all?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSk1pJAAoJEBzwKT+lPKRYUXgP/3e4+xfJIAieTw8U9ohtvLfZ
Jjl65dwjlhCRH26imhqIK9MK3w9ox+odGpjSlMM+cUPYgiIGZhxbFtUvLOigdkW4
0ENutvSzXg/mLdrDVM035IjRJMSXyIjk4Av2Wc+kJOeSyNEKREClN9Kgjojx2y44
8GoaoZCNhXgI76JfqBIgwidxrLhECS7Y5UIWzuDI0bsW0x6r1B5VhZdQBnpp2t9g
6Eb3BmfA8fE4hZYjkimKEvPCdryB/+lFuDgf5dBMIUVAemMK1fl+yn4hCaL9MKbY
DJnJeEM7Keu9KaYY4hQxQg9do/y7CNWMTqIfpB0/L2fYEu4HriNItQm0sATJ8XYB
Kjkd7TP0NU1lyhQLI7ikbkDDA/48oYBS0GkvN3F1TNYENyRuNW9fzUNMEPp6cXvd
HH5vPGn4NerJpdXq5wV6m0zVXCuOyl9uUDuP0LRHzx9fkA991RcxYqR4m21kHugD
Qi31kvw3klUJfPls7oRAY0LQJ2E3+sjGbtPccvCo4reQoxh1w7BcRxRKxwh63nKE
Cb4ITADi3qITfPRmRIHUVlDk/YD5/c2jZXxWU8Ecw4UwD9Aa9PsYzjwD2hkPBgGx
mvcTA4q0Lep8MZg+Il2/2sN0wAvMBRY8eu6fkDpFMrkDzEkYEa8jbx0znQYDeJBx
7CmJMGl2LBOcIJu1s55h
=vBKG
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: [OT] Issue with cgi/perl webpage

[Felipe <fe...@gmail.com>]

Interesting, so do container-based systems such as Tomcat rely heavely on
httpd? I've read that many people use Tomcat just for webapp deployment and
use apache to handle static pages, among other things, but is it reasonable
to use Tomcat to handle static pages, or is it solely for webapp server?
 Thanks Neven, I was able to get the cgi script working, I'm in the process
of dissecting and writing the steps to have tomcat host the cgi-script for
my professor, we talked and he saw that apache was what was meant to be
used but he encouraged my efforts in using Tomcat instead. Even if it isn't
the logical way to the exercise. There's a possibility that they might use
the this as an example of Tomcat's cgi support.
I'm actually interested in using Tomcat for a personal project. It is using
an Arduino Uno microcontroller (an AVR microcoontroller, specifically
Atmel's ATMEGA 328), I would like to use the arduino as a server that could
handle requests by way of a web interface control panel. I think this is
would be an appropiate scenario to use JSP and Tomcat. Initially I would
create a simple webapp that has prompt (where a user can input a command
that the arduino will then act on) and  display analog reading's (so as to
monitor). I'm just no sure how to go about hosting tomcat, I'm pretty sure
it is not possible to run on the arduino, but maybe using port forwarding
or web socket to have Tomcat on a laptop or maybe a rasberry pi. Would this
be a feasible method?


On Thu, Nov 21, 2013 at 8:36 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Neven,
>
> On 11/20/13, 11:48 AM, Neven Cvetkovic wrote:
> > Ultimately, CGI is a very old technology that had its own share of
> > performance (and security) problems. Usually, CGI scripts were
> > replaced with superior Java Servlet technology (or some other
> > better technology) and hence the need for Tomcat application server
> > (servlet container). Hopefully, the rest of the mailing list
> > members share my sentiments about the CGI :)
>
> - -0
>
> The only thing that really makes CGI "outdated" is that CGI itself
> didn't have an API... or if you could call it an API, it was very
> basic. It basically said "you get the query string in a big blob and
> you can read standard input if you want to get the entity body". Then
> everyone set to work writing their own custom parsing routines. I
> remember copy/pasting stuff in Perl way back in 1994 and now having
> any idea what the code actually did.
>
> These days, you can pretty much write a Perl script and say "use CGI;"
> and it's just magic, safe, etc. CGI has come a long way.
>
> The last remaining problem is really that of performance: the CGI
> model launches a new process for each request (even though you can
> cheat a bit using things like mod_perl, etc.) and so there is a
> performance hit right there. If you want to keep information between
> requests, you have no choice but to write it to some form of
> non-volatile storage (as far as the "application" is concerned).
> RDBMS, flat file, etc.
>
> More recent systems (I hesitate to say "modern" because it implies
> that they are better simply because they are newer, and that the older
> methodologies are simply worse by definition) are supported by much
> more complicated software, APIs, etc.
>
> Note that container-based systems like Tomcat have their own
> performance problems: they have to manage all the stuff that they are
> ... well, required to support. If you peel-away all of the stuff that
> Apache httpd provides *aside* from the Common Gateway Interface, you
> are left with a server that primarily pumps bytes back and forth
> between the client and the script. Tomcat has all kinds of moving
> parts that make it possible to do nice things, but those moving parts
> have a cost.
>
> (It's worth noting that I believe such costs are worth it. That's why
> I live in the container-based world instead of writing Perl- or
> PHP-based applications.)
>
> Want to deploy a single "Hello, World!" CGI script? No problem. Just
> drop "#!/bin/sh\n\necho "Hello, World!" into a .cgi file in your
> document root and tell Apache httpd it's okay to run it.
>
> Want to deploy a single "Hello, World!" script on Tomcat? Well, first
> you have to know where the auto-deployment directory is (hint: it's
> not a document root), and then you have to create a directory in
> there, and then drop a .jsp file in there. The good news is that
> "Hello, World!" is a valid JSP file without any of the fluff you need
> to make a shell script run. But the small amount of orientation
> required just to get the point of dropping text into a file can be
> confusing.
>
> Once the almighty "container" is involved, there is pressure to make
> it do more things. Sessions. Replication. Websockets. These are all
> very good and very useful things, but it further complicates the
> scenario. It's just a tough world to jump into with little to no planning.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSjrUUAAoJEBzwKT+lPKRYdcsQAIWqzHUbSimrUmXcYw9KH0zs
> fkZCQvi3Hqon1afyun6fU+NT8Ta0YkOYKW8gEiWvrogcZtMl1Q/oxOKSWZvPG8g1
> 8nPyDbACRL2715VUKuWgCTfABuQnHYOjFuakqAfZsXcVigxfpwWyw8eS7KfwpaDv
> vr/ZwqDv2ThQs63rk2rO5HW9o65nk2+XX4RBaUAw6lRZ7AfKMH5upR5Qwe231aKR
> DBF6GsuoWGeyONPXyGGIcrjLeizg1pOf1m0W3cTTIgI6UBNFUez+hZHGpFxbkrNE
> FX3onEVfrjlaxfSFmDx4ytDyOo973fhMALrasvIUSPqdKhjvIFHTYarZHRrOxex1
> /L+YWnth7xAWTHPz+SzM7YWzRTDfWeOMq9PCx8wdoV88BJ35tQerxowdvbo+fPJN
> S+Y+zw2iZwlyN8bVfwVpG81my8SEtFgrxhyPZMTqDK8RppL1QlC+aemQHiafTwoH
> 78+JP1HRR/tgYM9WXsDmOhIFgZp2pjATvuklqc5gw7BWX6J9UF8LjqEAmgwj5/KI
> JlcMgCLH91WvjU/7p0jFnTMGHalL8Bz4L4KFp9OwA4gwkvjZQF1q1MbEGU/GVHP+
> z2hJHeC4ugXk9zzO9imlUMZhC/pNGkwc/5leSMaHhwd0uZMatKh3sM4LLmoptiDP
> 0/kSWWI/zKK0USODk240
> =21G3
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Luis Felipe Hernandez