intro: web requests and responses

Slides of this lecture are at client-server-1.pdf.

When you visit a web page, what happens?
- A file: www.radford.edu/ibarland/Info/chars-to-check.shtml
  (…or, colors, generated from a pollen program. )
- A file with images: editfast.com/english/editpops/proofreaders_marks.htm
- Requesting directories:
  - www.radford.edu/ibarland/ — hand-generated html from where?
  - www.radford.edu/ibarland/Info/ — same directory as previous (but on a different server)
  - alumni.soe.ucsc.edu/~ian1/Info/ — different server gives same results…except no extra "/" in the h1?!
  - www.nytimes.com/2013/01/ — folder doesn't exist??
- File doesn't exist: www.homestarrunner.com/asdfasdfasdf, or www.soe.ucsc.edu/blah-blah-blah/qzqasdf
  (Btw, here's a 5-min TED talk on how a business can learn from rethinking its 404 page experience. The first 3min are annoying, but the final lesson is sound.)
- A page with GET params: e.g. www.clipart.com/en/search/split?page=5&cid=5m; we can change play with the params (but it's still the same 'page')
- Some hairy URL like maps.google.com/?ll=37.235094,-80.420677&spn=0.000536,0.000916&hnear=1600+N+Main+St,+Blacksburg,+Virginia+24060&t=h&z=20&vpsrc=6
- What about tinyurl.com/7efr7fy — what is happening here?
- An amazon item. What if we change the case of “amazon.com”? What if we change the case of the remainder of the URL? Say, this simple group card-game, and then we change some text...
  This really makes it hit home: the server is getting a string(URL), and doing whatever it likes with that! If it returns a string of html, it's certainly compliant (and it can also return other things, like a 404 error. So as long as it returns any valid http response, then it's compliant).
  
  Similarly, here are four URLs which all serve up the same result:
- A basic php page: hello-world.php. Here is the exact same page again, except re-named with suffix “txt”.
  There are three layers to be aware of: the original php program (just a program), the string(html) printed by the program, and how the browser renders that string(html).
  Key Concept: Be sure to understand the three different things:
  - The source of the .php program -- that's what is sitting on the server's computer.
  - The characters that happen to get printed, when you run the program. That's what the server will send back to the client (browser); it's what you see if you choose Show Source in your browser. Hopefully these characters start with “<html>…” or so.
  - The way that the browser choosed to render the characters it receives.
  We're used to the 2nd and 3rd items from Web I; the 1st item is adding yet another layer.

So:

A web server is just a function that accepts a string (a URL), and returns a string (of html). We'll update this slightly, below (they're not strings, but rather http packets, which may have additional info.)
A web browser is just a function that (a) accepts mouse-clicks from the user, and probably (b) decides what URL to send to what web-server, and (c) takes the response and renders it as pixels on the screen. Part "c" is what we usually think about, and that's a function from string to void [side-effect: draw on screen].

upshot: So, the essence of the situation is that the server and browser are functions with the type-signatures:
server : string → string (or, if you have very specific classes, Url → HtmlStr)
browser : string → void (or HtmlDoc → void).

        Client                             Server

        Browser            ->request->
                            (URL)
                                           WebServer (Apache)
                                             - look up file:
                                             - possibly redirect...
                                             - what if file exists, but no permissions?
                                             - what if file doesn't exist?
                                             - what if URL is a directory?
                                             - what if request from a mobile platform?
                                             - process any php (as configured)
                                               which may invoke other programs, db connections, etc
                            <-response<-
                            (html, jpg,
                             html+javascript,
                             ...)
        
       Browser
        ...makes a gui window,
           lays out text/color/pictures
           Displays response
        Also:
        ...makes add'l URL requests... [Ad blocker!]
        ...runs javascript...
        ...invokes plug-ins or passes to OS...

A couple of choices made by web servers we care about:

The server www.radford.edu, if asked for a URL of the form someUser/someDir/someFile.html, will look for the file /homedir/someUser/public_html/somedir/someFile.html.
(Note that /homedir/yourUsername is mounted as your H: drive.)
The server php.radford.edu, if asked for a URL of the form someUser/~someDir/someFile.php, will look for the file /homedir/someUser/dynamic_php/somedir/someFile.php.

Further things to mention (if not today, then perhaps later:)

starting up at Starbucks, when you get 'welcome to our wireless; please agree to our terms'.
telling my phone to use RUWireless, even not in browser a page comes up w/ "please authenticate"
Q: are URLs case-sensitive? How might you experiment, to find out?
What is the file that gets looked up, by the www.radford.edu web server? By php.radford.edu ?
sites that pop up 20 other windows (usually adverts)? Whose fault is that?
Referring page is often given ... Shriram's security leak.

This page licensed CC-BY 4.0 Ian Barland
Page last generated Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu