home—lects—exams—hws
D2L—breeze (snow day)

intro
intro: web requests and responses

When you visit a web page, what happens?
- A file: www.radford.edu/ibarland/Info/proofreader-marks.html
- A directory: www.radford.edu/ibarland/Info/
- Another directory: http://www.radford.edu/ibarland/
- Yet another directory: www.nytimes.com/2013/01/
- File doesn't exist: www.homestarrunner.com/asdfasdfasdf
  (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.nytimes.com/2010/07/25/magazine/25privacy-t2.html, as compared to addin “pagewanted=all”, a "GET parameter": www.nytimes.com/2010/07/25/magazine/25privacy-t2.html?pagewanted=all,
- 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).
- 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_url → string_html
browser: string_html → 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.

Looking more closely

For this class, you'll need a browser with good debug-tools built in. For Firefox, there is an extension “Firebug”; I'll demo a couple of Chrome's built-in tools. We will not worry about supporting old browers (e.g. old versions of IE).

≡ » More Tools » Developer Tools
We'll look briefly at the "Elements" tab, but today we're mostly concerned with the "Network" tab, and clicking on particular files. In particular, viewing the Request Headers and Response Headers.

Btw, here are the official HTTP response codes, or the cat-picture version.

the real upshot: So, the essence of the situation is actually that the server and browser are functions with the type-signatures:
server: http-request-packet → http-response-packet (where the first packet contains the URL, and the second packet contains the html response);
browser: http-response-packet → void.

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.

home—lects—exams—hws
D2L—breeze (snow day)

©2015, Ian Barland, Radford University
Last modified 2015.Sep.02 (Wed) Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

intro intro: web requests and responses

Looking more closely

intro
intro: web requests and responses