The Hypertext Transfer Protocol

The Hypertext Transfer Protocol
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Hypertext Transfer Protocol

The Process

The Process (cont.)

HTTP 1.1:
- Multiple requests can be made on one connection (a.k.a., Persistent HTTP)
HTTP/2:
- Multiplexing of requests by associating each exchange with its own stream
- Header compression
- Unsolicited push

Uniform Resource Identifiers

Defined:
- A means for identifying a resource
- Details are discussed in RFC 2396 and RFC 2732
HTTP URIs:
- http://Host[:Port]/Path[?QueryString]
- where the QueryString consists of name=value pairs delimited by the '&' character

HTTP 1.0 GET Requests

GET URI HTTP/1.0 CRLF
Name1: Value1 CRLF
Name2: Value2 CRLF
.
.
.
NameN: ValueN CRLF
CRLF

HTTP 1.0 POST Requests

POST URI HTTP/1.0 CRLF
Content-type: Type CRLF
Content-length: Bytes CRLF
CRLF
Data

Important Differences between GET/HEAD and POST Requests

Safety in HTTP:
- A request that is only accountable for the retrieval of information (and not any side-effects that might result)
GET/HEAD and POST:
- GET and HEAD are safe
- POST need not be safe

Important Differences between GET/HEAD and POST Requests (cont.)

Idempotence in Mathematics:
- A quantity is idempotent if it is unchanged by multiplication by itself (e.g., the number 1)
- A unary function/operator is idempotent if multiple applications yield the same result as a single application (e.g., the absolute value function/operator)
Idempotence in HTTP:
- The side-effects of \(N > 0\) requests are the same as for 1 request
GET/HEAD and POST:
- GET and HEAD are idempotent
- POST need not be idempotent

HTTP 1.0 Responses

HTTP/1.0 ResponseCode ResponseText CRLF
Name1: Value1 CRLF
Name2: Value2 CRLF
.
.
.
NameN: ValueN CRLF
CRLF
Data

HTTP Response Codes

(Courtesy of Saturday Morning Breakfest Cereal)

Try It Yourself!

Nerd Humor

API

(Courtesy of xkcd)

What Does a WWW Browser Do?

Let's figure it out

Cookies

Cookies (cont.)

From User Agent to Server (in an HTTP Request):
- Sent in a Cookie header
From Server to User-Agent (in an HTTP Response):
- Sent in a Set-Cookie header
Cookie String Format:
- name=value[; attribute=setting]...
HTTP Header Examples:
- Set-Cookie: affiliate=ExpertTravelLLC
- Set-Cookie: session=1561778; Expires=Wed, 29 July 2015 09:00:00 GMT
- Cookie: theme=Ocean

Third-Party Cookies

The Old Standard:
- RFC 2109 and RFC 2965 specified that user agents must reject a cookie if "The value for the Path attribute is not a prefix of the request-URI" or "The value for the request-host does not domain-match the Domain attribute".
The New Standard:
- "grants user agents wide latitude to experiment with third-party cookie policies that balance the privacy and compatibility needs of their users"