Perl CGI: Web Client Server Architecture

• 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:

• 1. Pat the user types a URL into their web browser, in this case http://localhost/cgi-bin/counter.pl and hits return.
  
  
  2. 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".
  
  
  3. 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.
  
  
  4. 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).
  
  
  5. 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.
  
  
  6. 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/".
  
  
  7. 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.
  
  
  8. 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.
  
  
  9. 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.
  
  
  10. 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 :) .