Client-Server Paradigm

• smtp
• EchoServer.java EchoClient.java
• http (web server), netscape (client)

Protocols

• Protocols define
  • message format
  • order of messages sent and received among network entities
  • actions taken on message transmission, receipt
  • In general, they define
    • Syntax of messages: use a grammar (ie BNF or FSM)
    • Symantics of messages: document each message type
    • Syntax of conversation: grammar (again BNF or FSM)
    • Symantics of conversation: document the states of the FSM, label the edges with actions.
  • A protocol allows separate groups to write clients and servers that can talk to eachother.
  • It defines what a good conversation looks like, it does not define how the clients or servers are implimented.
• Examples: ethernet, TCP, IP, HTTP (we will jump into this one).

HTTP (HyperText Transfer Protocol)

For a request, INITIAL LINE could be GET or POST or DELETE or HEAD. It includes the URL encoded resource as well as the HTTP protocol version number. The HEADER specifies things like Host: ... Cookie: ... The BODY of a request contains any payload data. For example, in a POST request, used to transfer a file from the client to the server, the file data appears in the http request body. Similarly, a form with method=POST will have the URL encoded data in the body of the http request.

For a responce, the INITIAL LINE has the status of the request (ie HTTP/1.1 200 OK, HTTP/1.1 404 Not Found), the HEADER contains things like Set-cookie: , Last-Modified:, Content-Type:, ... The BODY contains the payload of the responce. For example, the HTML for the webpage, the image, ...

Example

Example

References

• HTTP 1.1 RFC
• WWW Consortium. The architects of the web.
• Easy guide to HTTP
• HTTP as a state machine

HTTP (HyperText Transfer Protocol) Details

• Purpose: Deliver content over the WWW
• Pieces: Browser is HTTP client, web server is HTTP server.
• Resource: HTTP transmits these, could be files or other dynamically generated data.
• Protocol:
  • Client connects to server, issues request, server responds, connection is closed.
  • Message format: (all lines CRLF terminated). Everything except body must be ascii (text)

Http Examples

telnet to www.cs.toronto.edu port 80 (make sure that each line ends with CRLF)
That is, 

telnet www.cs.toronto.edu 80

GET /~arnold/309/http/hello.html HTTP/1.0

GET /~arnold/309/http/hello.html HTTP/1.1
Host:www.cs.toronto.edu

GET /~arnold/309/http/hello.html HTTP/1.1
Host:www.cs.toronto.edu
If-Modified-Since: Mon, 06 Jan 2003 11:11:11 GMT

GET /~arnold/309/http/hello.html HTTP/1.1
Host:www.cs.toronto.edu
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 

GET /~arnold/309/http/anotherDocument.html HTTP/1.1
Host:www.cs.toronto.edu

DELETE /~arnold/309/http/anotherDocument.html HTTP/1.1
Host:www.cs.toronto.edu

HEAD /~arnold/309/http/saturn_family.jpg HTTP/1.0

GET /~arnold/309/http/saturn_family.jpg HTTP/1.1
Host:www.cs.toronto.edu

Summary of HTTP commands

• GET a specified resource
• DELETE a specified resource
• HEAD get the responce headers (without associated data)
• PUT accompanying data at the specified location
• POST accompanying data as a subordinate to the specified location.

Notes

• HTTP 1.1 requires that you specify the host name you are requesting the resource from. This allows one IP to be associated with many 'web sites'. The web server checks the Host field to determine which site the location refers to.
• Returned headers include: HTTP version, return code, responce date, server type, allowed operations, how return data is encoded, a description of the returned data type.

  HTTP/1.1 405 Method Not Allowed
  Date: Wed, 16 Jan 2002 04:48:24 GMT
  Server: Apache/1.3.19 (Win32)
  Allow: GET, HEAD, OPTIONS, TRACE
  Transfer-Encoding: chunked
  Content-Type: text/html; charset=iso-8859-1
  

Authentication

• Require username/password to access content
• Access to restricted content requires (for Basic authentication) the following header to accompany ALL requests for protected resources.

  Authorization: Basic YXJub2xkOnByb2Y=
  

  The part after Basic is a Base64 encoding of userid:password. In this case, the above encodes "arnold:prof".

Authentication Examples

• http://www.cs.toronto.edu/~arnold/309/phttp/hello.html
• Try obtaining the resource with and without the Authorization line below.

  GET /~arnold/309/phttp/hello.html HTTP/1.1
  Host: www.cs.toronto.edu
  
  GET /~arnold/309/phttp/hello.html HTTP/1.1
  Host: www.cs.toronto.edu
  Authorization: Basic YXJub2xkOnByb2Y=
  

• Your browser remembers to place the Authorization header at every request to related resources (otherwise you would have to enter id and password at each request).

Authentication and the Apache Web Server

• Create password file, with user names and passwords. The contents of my passwd file can be found below. It says that arnolds password is prof and joes password is student.

  arnold:$apr1$qe2.....$PhSXQ.GvNdBVzxS/GVkJR0
  joe:$apr1$cg2.....$AbIos1EJ.ofCVkkGUpFpZ0
  	

• Restrict access for any resource below a directory by placing an .htaccess file in it. The contents of the .htaccess file for phttp can be found below.

  AuthType Basic
  AuthName "By Invitation Only"
  AuthUserFile "/home/a/arnold/public_html/phttp/passwd"
  Require user arnold joe
  	

Cookies

• Note: Examples can be found at chttp.zip, or see Cookie examples
• Part of http headers NOT part of data!
• Server can include

   Set-cookie: name=value 

  header in responce.
• Client includes a

   cookie: name=value 

  header for each cookie it wishes to communicate back to the server.
• Client typically includes all relevent cookies in all requests to a server. Relevent cookies are those set by the server.
• Cookies are used to maintain session information. That is, add state to a stateless protocol.
• Server usually associates cookies with previous choices, login information etc.
• Example: GET /cgi-bin/mycookiecgi.cgi HTTP/1.1 Host: www.cs.toronto.edu
• Details (from developer.netscape.com): Set-Cookie: name=value [;EXPIRES=dateValue] [;DOMAIN=domainName] [;PATH=pathName] [;SECURE] name=value is a sequence of characters excluding semicolon, comma and white space. To place restricted characters in the name or value, use an encoding method such as URL-style %XX encoding. EXPIRES=dateValue specifies a date string that defines the valid life time of that cookie. Once the expiration date has been reached, the cookie will no longer be stored or given out. If you do not specify dateValue, the cookie expires when the user's session ends. The date string is formatted as: Wdy, DD-Mon-YY HH:MM:SS GMT where Wdy is the day of the week (for example, Mon or Tues); DD is a two-digit representation of the day of the month; Mon is a three-letter abbreviation for the month (for example, Jan or Feb); YY is the last two digits of the year; H H:MM:SS are hours, minutes, and seconds, respectively. DOMAIN=domainName specifies the domain attributes for a valid cookie. If you do not specify a value for domainName, Navigator uses the host name of the server which generated the cookie response. Example: DOMAIN=royalairways.com matches hostnames anvil.royalairways.com and ship.crate.royalairways.com PATH=pathName specifies the path attributes for a valid cookie. If you do not specify a value for pathName, Navigator uses the path of the document that created the cookie property (or the path of the document described by the HTTP header, for CGI programming). Example: PATH=/foo matches /foobar and /foo/bar.html The path "/" is the most general path. Should a browser send back a cookie? sendCookie(){ for(each cookie stored in cache){ if(DOMAIN matches){ if(PATH matches){ send cookie } } } } SECURE specifies that the cookie is transmitted only if the communications channel with the host is a secure. Only HTTPS (HTTP over SSL) servers are currently secure. If SECURE is not specified, the cookie is considered sent over any channel.
• secrets.php

URL, URI and Encoding

References

• rfc3986

CGI

To plug into a web server, your program will need to know where to expect inputs and where to place outputs. The CGI protocol specifies this. Your program need only look in appropriately prepared environment variables and in stdin for its inputs. Your program need only write an appropriate responce for output. Consider the http request that arises from the following URL.

References

• rfc3875