Web Servers

• Review basic HTTP protocol and messages sent between the client and the server.
• At first, a URL was a machine name and a filename.
• Server simply opened the file and sent it back.
• Example: https://github.com/kurmasz-SampleCode/CIS371-SampleCode/tree/master/SimpleHTTPServer
  • cd ~/Documents/Courses/KurmasGVSU.github.io/Teaching/Courses/W24/CIS658/
  • java -cp ~/Documents/Courses/CIS371/SampleCode/SimpleHTTPServer HTMLOnlyServer
  • visit index.html
  • Notice the command received: GET /index.html HTTP/1.1
    • Line 42: String command = input.readLine();
    • Split into three pieces. Line 54: String[] parts = command.split("\\s+");
    • Open file
    • Print headers
    • print blank line
    • Loop through and take from file and send as response.

“Hard-Coded” Dynamic Server

• What happens when you enter a directory instead of a file?
  • Return index.html if it exists.
  • Return a directory listing otherwise (sometimes.)
    • Demonstrate with built-in Python server running local copy of my web page
• Key idea: The “path” part of a URL is just text. It has no official semantic meaning.
  • The web server can treat/interpret it however it wants.
• Show ServerWithWhoCommand
  • whoText
  • whoHTML

Generalized Dynamic Server (CGI)

• Having to customize an entire web server to run code specific to your app is not ideal.
  • Creating/Maintaining a web site and a web server requires two very different skill sets.
    • In some sense, the web server code is much “lower” level.
  • Separate the two so those responsible can focus on their area of strength.
• Idea: If a file name has a programming language extension (.pl, .py, .php, etc.) and/or in the cgi-bin directory, run that file and send the resulting output.
  • Uses fork and exec, for what it’s worth.
• What are some “rough edges” with this approach?
  1. Writing a program that generates HTML as output is messy
     • See whoHTML in https://github.com/kurmasz-SampleCode/CIS371-SampleCode/blob/master/SimpleHTTPServer/Who.java
  2. We need a way of passing parameters to the program. (e.g., what zip code do you want the weather for?)

Passing “parameters”

• Imagine you are writing a web app that shows the current weather.
• You need some way for the user to specify which city/zip to display.
  • Ideas?
    • Path
    • Query string
    • POST
  • Pros/Cons?
• URL:
  • Remember that the server can interpret the path any way it likes.
  • http://myweather.com/today/49401. First part of path could be the page, second part the zip code.
  • Challenge?
    • The server has to be customized to interpret the path properly.
• CGI: Common Gateway Interface
  • Original standard for specifying how a web server sent parameters to the external program.
    • https://www.w3.org/CGI/
    • https://en.wikipedia.org/wiki/Common_Gateway_Interface
  • Part before ? was name of script to run.
  • Part after ? was the parameters.
  • e.g., http://myweather.com/today.php?zip=49401
  • Notice the key/value pair.
• What details need to be worked out to make this work?
  • How to handle multiple parameters?
  • How to handle escaping ?, &, =, etc.?
  • How to handle spaces and unprintable characters?
• Do a google query and look at the URL.
• Visit https://faculty.computing.gvsu.edu/kurmasz/formDemo.php and examine GET URLs generated.
• CGI defines a standard for all of this.
• POST:
  • You can also send data in the body of the request.
  • Remember the blank line after the request headers? POST data goes after that.
  • Visit https://faculty.computing.gvsu.edu/kurmasz/formDemo.php and examine the POST request generated (using Network -> Payload in developer tools)
• (More on GET vs. POST later.)
• Old CGI workflow:
  • Server would separate the query string from the path and send it as input to the external script, and
  • Server would read body from POST requests and send it as input to the external script.
  • All external scripts were responsible for parsing these parameters to obtain useful information.
  • This was usually done by common libraries to avoid duplicating code.
• Early goal: “Automate” the handling of these parameters to minimize redundant code that must appear in each script.

Writing programs that generate HTML.

• If done naively, writing programs that produce HTML as output can be quite messy.
• Idea 1a: String interpolation.
  • print(f"The value of x is {x}")
• Idea 1b: “Here” documents
  • Analogous approaches in many languages.
  • Pretend that the line name = "bob" is a function call that does something like get weather data, looks up a flight status, etc.

name = "bob"

doc_string = f"""
   <html>
     <head>
        <title>My Dynamic Web Page</title>
     </head>
     <body>
     <h1>Welcome</h1>
        Hello, {name}!
     </body>
   </html>"""
   
print(doc_string)

• “Old school” CGI perl programs looked something like this:

use POSIX;

my $time = strftime "%H:%M", localtime time;

print <<HERE
<html>
<body>
<h2> Hello, World!</h2>

<p>At the tone time time (at the server) will be $time.</p>

(from perl)
</body>
</html>
HERE

• Notice that the bulk of the code is HTML, not python/perl. This seems kind of backward.
• The next advancement was PHP which made the content of the “here” document the default, and the code was “escaped”.
  • https://github.com/kurmasz-SampleCode/CIS371-SampleCode/blob/master/Templating/colorDemo.php
• This is not a bad idea at all — many, many web sites generated using PHP.
• Limitations of PHP? Why is it not so popular?
  • It was the first attempt at smoothing out the rough edges.
  • First version was very simple / “quick and dirty” (e.g., no “OO”)
  • Newer ideas often “bolted” on awkwardly
• As a result, many other approaches use the same key ideas, but are more elegant.

Frameworks

Imagine you are designing a system to create dynamic web pages. What types of features are you looking for? * A library of functions to do common tasks (so you don’t have to re-invent the wheel) * You might want to have your system just automatically call these functions for you saving even more time. * Frameworks are the result of these attempts to automate as much as possible allowing users to implement a web page with as little coding as reasonable. * When designing a framework, there is a fundamental tension between configuration and convention. * What things should be explicitly spelled out? * What things should just happen by “magic” if the code is written using certain names/patterns? * There is no right answer, which is why there is a long list of frameworks. * However, frameworks tend to follow similar patterns and have a number of things in common. * So, the goal here is not to make you an expert using any particular framework, but to highlight common patterns/techniques so that when you go to learn a specific framework, it doesn’t seem completely foreign and you have a mental model you can leverage.