(6) HTTP Messages

• HTTP needs a reliable connection
  • the foundation for HTTP is the Transmission Control Protocol (TCP) [Internet Architecture; Transmission Control Protocol (TCP) (1)]
  • DNS resolution yields an IP address
  • open TCP connection to port 80 or port specified in URI (http://rosetta.ischool.berkeley.edu:8085/)
• HTTP is a text-based protocol
  • the connection is used to transmit text messages
  • all HTTP messages are human-readable (not all entities, though)
  • basic HTTP operations can be carried out by hand

start-line
message-header *

message-body ?

(7) HTTP Header Fields

• Header fields contain information about the message
  • general header: Date as the message origination date
  • request header: Accept-Language indicates language preferences
  • response header: Server contains system information
  • entity header: Content-Type specifies the media type of the entity
• HTTP defines a number of header fields [http://www.cs.tut.fi/~jkorpela/http.html]
  • unknown fields must be ignored (extensibility)
  • unstandardized fields should use a X- prefix
• HTTP is about acting on these fields
  • HTTP defines what HTTP implementations must or should do

(8) HTTP Content Negotiation

• HTTP Header Fields [HTTP Header Fields (1)] have interaction semantics
  • depending on the header type they convey different information
• HTTP Content Negotiation [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html] allows representation negotiation
  • the client specifies a number of preferred content properties
  • the server responds with the representation that fits best
• Server-driven negotiation can use a number of request header fields
  • Accept uses a list of Media Types [Media Types]
  • Accept-Charset uses a list of character sets
  • Accept-Encoding uses a list of content encodings
  • Accept-Language uses a list of language codes
  • User-Agent specifies the client's identification
• Client-driven negotiation lets the server send a list of URIs
  • two steps are required to get the best alternate representation

(9) HTTP Requests

• After opening a connection, the client sends a request
  • the method indicates the action to be performed on the resource
  • HTTP's most interesting methods are: GET, HEAD, POST
  • other interesting methods are: PUT, DELETE
• The URI identifies the resource to which the request should be applied
  • absolute URIs are required when contacting proxies
  • absolute paths are required when contacting a server directly
  • the URI may contain query information
• The Host header field must be included in every request

Method Request-URI HTTP/Major.Minor
[Header]*

[Entity]?

(10) HTTP GET

• Retrieval action based on the URI
  • maybe implemented by reading a file
  • maybe implemented by processing a file (PHP)
  • maybe implemented by invoking a process
• Semantics may change based on header fields
  • If-*: only reply with the entity if necessary
  • Range: only reply with the requested part of the entity
• Cacheability depends on header fields of the response

GET / HTTP/1.1
Host: ischool.berkeley.edu

(11) HTTP Responses

• The server's response to interpreting a request
  • the status code is given numerically and as text
  • 2** for variations of ok
  • 3** for redirections
  • 4** are different client side problems (404: not found)
  • 5** are different server side problems
• Header fields specify additional information
  • information about the server
  • information about the entity (media type, encoding, language)

HTTP/Major.Minor Status-Code Text
[Header]*

[Entity]?

(12) HTTP Performance

• HTTP/1.0 allowed one transaction per connection
  • TCP connection setup and teardown are expensive
  • TCP's slow start slows down the initial phase of data transfer
  • typical Web pages use between 10-20 resources (HTML + images + CSS + scripts)
  • typically, these resources are stored on the same server
• HTTP/1.1 introduces persistent connections
  • the TCP connection stays open for some time (10 sec is a popular choice)
  • additional requests to the same server use the same TCP connection
• HTTP/1.1 introduces pipelined connections
  • instead of waiting for a response, requests can be queued
  • the server responds as fast as possible
  • the order may not be changed (there is no sequence number)

(13) HTTP Connection Handling

(15) HTTP Access Control

• HTTP servers can deny access [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error] through access control
  • 401 Unauthorized means the resource is access controlled
  • 403 Forbidden means the resource is inaccessible
  • 405 Method Not Allowed signals a request using the wrong request method [HTTP Requests (1)]
• Two different approaches to unauthorized access are possible
  • repeat the HTTP request with the proper authentication credentials
  • redirect to a Login Page [Login Page (1)] and establish an authenticated session

(16) HTTP Authentication

(17) Basic HTTP Authentication

• Authentication is based on authentication realms
  • a set of resources for which the authentication is required
  • an opaque name which is used to signal which login is required
  • username/password often is specific for a given realm
• Users supply username and password through the client
  • sent as Base64 [http://en.wikipedia.org/wiki/Base64] encoded username:password string
  • username and password are not transmitted securely [http://www.google.com/search?hl=en&q=base64+decoder]
  • basic authentication should always use HTTPS [Security & Privacy; HTTP over SSL (HTTPS) (1)]
• Authorization is handled on the server side

  HTTP/1.0 401 Unauthorized
  WWW-Authenticate: Basic realm="SokEvo"

  [http://en.wikipedia.org/wiki/Basic_access_authentication]

  GET /private/index.html HTTP/1.0
  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

  [http://en.wikipedia.org/wiki/Basic_access_authentication]

(18) Repeated Access

• Clients typically access more than one protected resource
  • a perfectly stateless client would always request authentication from the user
  • using the realm clients can identify repeated accesses
• Web interactions by default are perfectly stateless
  • each request is completely independent from other requests
  • stateless interactions make the Web loosely coupled and scalable
  • concepts like the realm or Cookies [Web Storage; Cookies (1)] introduce state
• Clients remember the authentication and replay it automatically
  • browsers provide little control over this feature
  • logging out of HTTP authenticated sessions is hard

(19) Login Page

• Basic HTTP Authentication [Basic HTTP Authentication (1)] works with browser controls (including the window)
  • no possibility to log out without using browser-specific controls
  • client side security depends on browser security measures
• Using HTML Forms [HTML Forms] gives more freedom in session management
  • Authentication [Security & Privacy; Authentication (1)] and Authorization [Security & Privacy; Authorization (1)] are completely application-based
  • if there were secure personal browsers this would not work very well