Perl CGI: Web Client Server Architecture
Prepared by Bill Kilgallon,
Bill@KilgallonFamily.com
- Suprise! A web client (like the Internet Explorer Browser) talking to
a web server (like Apache) is a client server architecture.
- A web server just serves up answer after answer to incoming
questions. They don't naturally build relationships, establish
friendships, or even care who you are or where you are coming from.
You appear, ask them a question, they answer your question then they
forget you forever. You ask another question a second later, and they
look at like you like they never saw you before.
- The fancy way of saying this is that interactions between a web
server and a web browser are inherently stateless. Say it this way
when you want to intimidate co-workers or impress your boss. Say it
the otherway when you actually want to communicate to another person
what is actually happening.
- Heres what happens when somebody asks for your simple web counter page:
-
- Pat the user types a URL into their web browser, in this case
http://localhost/cgi-bin/counter.pl and hits return.
- Pat's web broswer establishes a connection across the internet
using well understood protocols (sockets on TCP/IP) to the host
(localhost) on port number 80. It sends a well behaved and predetermined message format indicating that it wishes to see the file "/cgi-bin/counter.pl".
- The web server at the IP address registered to the name
"localhost" is sitting there listening to port 80 and hears this
request. It grabs the IP and source port address (a large basically
random number) of Pat's browser.
- The web server looks at the address of the file Pat has asked for
("/cgi-bin/counter.pl"), and compares it to it's internal
configuration settings (in the case of Apache, httpd.conf).
- The web server notices that Pat has asked for a file starting
with the path "/cgi-bin", and that it has been configured such that
whenever people ask for files starting with that path it is supposed
to run a program instead of just returning a file.
- Having decided that it is supposed to run a file, the web server
looks at the rest of the address requested by Pat's browser to figure
out which file to run. In this case, it sees "counter.pl". It again
looks at it's configuration file, and notices that it is supposed to
find all programs to execute in the directory "C:/Program
Sources/Apache/Apache Group/cgi-bin/".
- The server figures out how to actually go about executing this
file (is it an executable program? A visual basic script? A perl
script?), and then launches this program, runs it until it exits
completely, and takes all the text it output and writes it back
to the ip address and port of Pat's browser.
- The server then forgets that Pat even ever existed, and goes on
to it's next adventure. If there is an error in the script, it drops
Pat like a hot potatoe, never speaks to Pat again, and leaves Pat
hanging until Pat times out and goes away.
- The server probably logs what Pat asked for, what Pat wanted, and
what time Pat was coming around. Also, if there was a problem finding
or running the thing Pat wanted, it logs this information as well.
- Pat's browser takes the big stream of data the web sever just wrote
back to it, and attempts to do it's best to interpret it as HTML
formatting instructions and to display the resulting graphics on the
screen.
- So what does this mean to you as the author of the CGI program?
It means that every time your program runs, it is like some guy in a
movie that comes out of a coma and can't even remember his own name.
Want to know how many visits to a particular page? Come out of the
coma, look at the pad of paper written down in front of you that says
"there have been 100 people that have viewed this page", erase the
100, write 101, announce "there have been 101 people visiting this
page", and promptly go back into your coma and forget
everything.
- As a developer of web CGI applications, this is the biggest
problem you will face, maintaining information for a particular
customer between requests.
- The fancy way to say "remembering information" is to say
"maintaining the state of a session" or simply "maintaining state".
Ways to manage this problem include embedding data into URL's, storing
information in cookies, or storing state in external databases.
- The file we open in our example is just an extremely simple
database. It does one thing for one user. Most databases do a
great many things for a great many users... but we are on the inner
loop on the happy path, what do you expect :) .
Return to Index