An HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 message is ordinary readable text, so you can type one by hand. Cookies then use two of its header lines to rebuild the memory that HTTP itself deliberately refuses to keep.
Words you will meet
- Request line — the first line of a request: what to do, to what, with which version.
- Header line — a “name: value” line carrying extra information.
- Status line — the first line of a response: the version, and whether it worked.
- Entity body — the part carrying the actual file, or the form data.
- Method — the word at the start of a request saying what the client wants.
- Status code — a three-digit number saying how the request turned out.
- Cookie — a small identity number a site gives your browser so it can recognise you later.
Why this matters
This is the first message format the book shows in full, and the friendliest one you will ever see. It is plain ASCII (American Standard Code for Information Interchange) American Standard Code for Information Interchange The 7-bit text encoding to which SMTP restricts mail bodies. introduced in ch. 2 text that an ordinary computer-literate human being can read. Every other format in this book — TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 segments, IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 datagrams, Ethernet frames — is a field of bits you need a tool to inspect.
Cookies matter for a different reason. Section 2.2.1 said HTTP is deliberately stateless. This section shows how the Web put state back without changing the protocol at all — a pattern worth recognising, because you will meet it repeatedly.
The request message
Here is a typical HTTP request message.
Five lines, and what they say
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: frWe can learn a lot from this. First, the message is written in ordinary ASCII text, so a human can read it. Second, it consists of five lines, each followed by a carriage return and a line feed, and the last line is followed by an additional carriage return and line feed. A request message can have many more lines, or as few as one.
The first line is the request line request line Simple The first line of an HTTP request: what to do, to what, with which version. Precise The first line of an HTTP request message. It has three fields: the method field, the URL field and the HTTP version field. introduced in ch. 2 — open in glossary , and it has three fields: the method http method Simple The word at the start of a request saying what the client wants done. Precise The value of the method field in an HTTP request line. GET requests the object named in the URL field, and is used by the great majority of requests. POST sends an entity body, typically the contents of a form. HEAD replies with the headers but leaves out the object, which is useful for debugging. PUT uploads an object to a specific path on a server, and DELETE removes one. introduced in ch. 2 — open in glossary field, the URL (Uniform Resource Locator) Uniform Resource Locator The address of a single Web object: hostname plus path name. introduced in ch. 2 field and the HTTP version field.
The lines after it are header lines header line Simple A “name: value” line carrying extra information about a message. Precise A line following the request line or the status line, terminated by a carriage return and a line feed. It consists of a header field name, a colon, a space and a value. Which header lines appear depends on the browser type and version, its configuration, and whether it already holds a cached copy of the object. introduced in ch. 2 — open in glossary .
Click any box to read what that part of the message is for.
A real request — five lines, each ended by cr lf, then one more cr lf
GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu Connection: close User-agent: Mozilla/5.0 Accept-language: fr
Every field, as text
- method — What the client wants done. (example: GET)
- sp
- URL — The path name of the object being requested. (example: /somedir/page.html)
- sp
- Version — Which version of HTTP the client implements. (example: HTTP/1.1)
- cr
- lf
- header field name: — The name of the header, ending in a colon. (example: Host:)
- sp
- value — What the header says. (example: www.someschool.edu)
- cr
- lf
- cr — The extra carriage return that ends the headers.
- lf
- Entity body — empty with GET, the form contents with POST — The payload of the request.
Every box is a real part of the bytes on the wire, including the invisible ones. Click any of them.
What each header line in the example says
| Line | What it does |
|---|---|
Host: www.someschool.edu | Specifies the host on which the object resides. |
Connection: close | Tells the server the browser does not want to bother with persistent connections — close after sending this object. |
User-agent: Mozilla/5.0 | Names the browser type making the request. Here, a Firefox browser. |
Accept-language: fr | The user prefers a French version of the object, if one exists; otherwise the server sends its default. |
Why Host: when a connection already exists?
You might think this header line is unnecessary. There is already a TCP connection in place to the host, so surely the server knows who it is.
It does. But the information in the Host: line is required by web proxy
caches, which section 2.2.5 covers. A cache sits between
the browser and many different origin servers, and one cache holds objects
belonging to many sites. Without the hostname written into the message itself,
it could not tell them apart.
This is a small example of a large idea. A message must sometimes carry information the connection already implies, because a device on the path does not share the connection’s context.
User-agent: earns its place too. The server can send different versions of
the same object to different types of user agent — and each version is
addressed by the same URL. Accept-language: is one of many content
negotiation headers.
The methods
| What it does | ||
|---|---|---|
| A form does not have to use POST. HTML forms often use GET and put the input in the URL: www.somesite.com/animalsearch?monkeys&bananas | ||
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Sort by how often you will meet them, or read down the reasons.
The response message
Here is a typical response — it could be the reply to the request above.
Click any box to read what that part of the message is for.
A real response — a status line, six header lines, then the object
HTTP/1.1 200 OK Connection: close Date: Tue, 18 Aug 2015 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data data data data data ...)
Every field, as text
- version — The version the server is using. (example: HTTP/1.1)
- sp
- status code — A three-digit number saying how the request turned out. (example: 200)
- sp
- phrase — The status code said in words. (example: OK)
- cr
- lf
- header field name: — The name of the header, ending in a colon. (example: Content-Length:)
- sp
- value — What the header says. (example: 6821)
- cr
- lf
- cr — Ends the headers.
- lf
- Entity body — the requested object itself — The meat of the message.
Almost the same shape. Only the first line differs: a status line instead of a request line.
The response has three sections: an initial status line status line Simple The first line of an HTTP response: the version, and whether the request worked. Precise The first line of an HTTP response message. It has three fields: the protocol version field, a status code and a corresponding status message. introduced in ch. 2 — open in glossary , six header lines, and then the entity body entity body Simple The part of an HTTP message that carries the actual file, or the form data. Precise The part of an HTTP message that follows the header lines and a blank line. It is empty with the GET method, carries what the user typed into the form fields with the POST method, and carries the requested object itself in a response. introduced in ch. 2 — open in glossary . The entity body is the meat of the message: it contains the requested object itself.
The status line itself has three fields: the protocol version, a status code status code Simple A three-digit number saying how the request turned out. Precise A number in the status line of an HTTP response, with an associated phrase, indicating the result of the request. Common ones are 200 OK, 301 Moved Permanently (the new URL is in the Location header), 400 Bad Request, 404 Not Found, and 505 HTTP Version Not Supported. introduced in ch. 2 — open in glossary , and a corresponding status message. In the example above the server is using HTTP/1.1 and everything is OK — it has found the requested object and is sending it.
The header lines in this example:
| Line | What it does |
|---|---|
Connection: close | The server will close the TCP connection after sending this message. |
Date: | When the HTTP response was created and sent by the server. |
Server: | Which server software produced it — analogous to User-agent: in a request. |
Last-Modified: | When the object was created or last modified. |
Content-Length: | The number of bytes in the object being sent. |
Content-Type: | What sort of object the entity body holds. |
Two dates, two meanings
Date: is not the time the object was created or last modified. It is the
time the server retrieved the object from its file system, inserted it into the
response, and sent it.
Last-Modified: is the one about the object. And it is
critical for object caching — both in the browser and in network cache
servers. Section 2.2.5 builds the conditional GET on it, and
that mechanism would not work at all without this line.
One more detail that catches people out: the object’s type is officially
indicated by Content-Type:, not by the file extension.
The status codes
| Phrase | What it means | |
|---|---|---|
| Included early because §2.2.5 needs it. A response can be useful precisely because it carries nothing. | ||
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
The first digit is the family: 2 succeeded, 3 go elsewhere, 4 your fault, 5 my fault.
Try it yourself
HTTP is text, so you can be the client. Open a command prompt and type:
telnet gaia.cs.umass.edu 80
GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.eduPress the carriage return twice after the last line — that is the blank line in the diagram above, and without it the server keeps waiting for more headers.
You will see a real response message. Replace GET with HEAD to see only the
header lines, without the object.
Where this breaks today: most public sites now redirect to HTTPS, so a plain telnet session will get 301 Moved Permanently rather than the page. That is the right answer, not a failure — and section 2.1.4 explained why the encryption is there. The exercise still shows you the format, which is the point.
Cookies: state without a stateful protocol
An HTTP server is stateless. That simplifies server design and has let engineers build high-performance servers handling thousands of simultaneous connections.
But sites often need to identify users — to restrict access, or to serve content based on who is asking. For this, HTTP uses cookies cookie Simple A small identity number a site gives your browser so it can recognise you later. Precise A mechanism, defined in RFC 6265, that allows sites to keep track of users. It has four components. Two are header lines: a Set-cookie line in the HTTP response, and a cookie line in later HTTP requests. Two are stores: a cookie file on the user’s end system, managed by the browser, and a back-end database at the Web site. Cookies create a user session layer on top of stateless HTTP. They are controversial because they can be considered an invasion of privacy. introduced in ch. 2 — open in glossary , defined in RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 6265. Most major commercial websites use them.
Cookie technology has four components, and it is worth noticing where each one lives:
- A
Set-cookie:header line in the HTTP response. - A
Cookie:header line in later HTTP requests. - A cookie file kept on the user’s end system, managed by the browser.
- A back-end database at the website.
In plain words
Look at that list again. Two of the four are header lines — parts of HTTP that already existed. The other two are files at the two ends.
Nothing in the protocol changed. HTTP is still stateless: the server still keeps no state in the protocol. The state sits in a database on one side and a file on the other, and two header lines carry a number between them.
Susan meets Amazon
Click any arrow to see what that message says and why it is sent.
Six messages over one week. Click any arrow to see the header line that carries the state, and what each side stores.
Read this diagram as text
- Susan’s browser sends usual http request msg to Amazon web server. Susan’s first ever visit. Her cookie file already holds a line for eBay from an earlier visit there, but nothing for this site, so the request carries no cookie header.
- Amazon web server sends usual http response + Set-cookie: 1678 to Susan’s browser. The server creates a unique identification number and an entry in its back-end database indexed by that number. It returns the number in a Set-cookie: header. The browser appends a line to its cookie file: the hostname, and the number.
- Susan’s browser sends usual http request msg + cookie: 1678 to Amazon web server. On every later request to this site, the browser consults its cookie file, extracts the number for this host, and puts it in a Cookie: header. The server looks 1678 up and takes a cookie-specific action.
- Amazon web server sends usual http response msg to Susan’s browser.
- Susan’s browser sends usual http request msg + cookie: 1678 to Amazon web server. One week later. The browser was closed, the machine was probably restarted, and the TCP connection from last time is long gone. None of that matters: the cookie file is on disk, so the same number goes back.
- Amazon web server sends usual http response msg to Susan’s browser.
Lifelines, left to right: Susan’s browser (host), Amazon web server (server).
Susan always accesses the Web from her home PC, and she visits Amazon for the first time. She has visited eBay before, so her cookie file already has a line for that site.
When her request arrives, the Amazon server creates a unique identification
number and creates an entry in its back-end database indexed by that number. It
responds with a Set-cookie: header containing the number:
Set-cookie: 1678Her browser sees the header and appends a line to its cookie file — the hostname of the server, and the number. As she continues to browse, each of her requests to that site includes:
Cookie: 1678Now the server can track her activity. Amazon may not know her name, but it knows exactly which pages user 1678 visited, in which order, and at what times. That is how the shopping cart works: the site keeps a list of everything she intends to buy so she can pay for all of it at the end.
If she returns a week later, her browser still sends Cookie: 1678, so the site
can recommend products based on what she looked at before. Suppose she also registers, giving her full
name, e-mail address, postal address and card details. The site can attach all of
that to the same number, and to every page she has ever visited there. That is
how one-click purchasing works.
The concern, stated plainly
Cookies often simplify shopping for the user. They are also controversial, because they can be considered an invasion of privacy.
Notice how little is needed for that to be true. Even before Susan gives her name, the site has an exact record of her behaviour. Using a combination of cookies and user-supplied account information, a website can learn a lot about a user and potentially sell that information to a third party.
The book states this without softening it, and so does this site.
Cookies can therefore be used to create a user session layer on top of stateless HTTP. When you log in to a web-based e-mail application, the browser sends cookie information with each request, which is what lets the server recognise you throughout the session.
Check yourself
Check yourself
0 of 6 answered1.A browser sends a request whose first line is `GET /somedir/page.html HTTP/1.1`. What are the three fields of that line?
2.There is already a TCP connection to the server, so why does a request still need a `Host:` header line?
Section 2.2.5 is the reason.
3.A form has two fields, and the user types `monkeys` and `bananas`. The form uses GET rather than POST. Where does the typed data go?
4.A response carries `Last-Modified:` as well as `Date:`. What is the difference, and why does it matter?
5.predictIn the cookie diagram, Susan returns to the site a week later. What does her browser put in the request, and what has the server had to remember?
6.The book says cookies are controversial. What exactly is the concern it raises?
What to remember
- A request is a request line (method · URL · version) plus header lines plus an entity body. A response is a status line (version · status code · phrase) plus header lines plus an entity body.
- 200 OK · 301 Moved Permanently · 400 Bad Request · 404 Not Found · 505 HTTP Version Not Supported. Also 304 Not Modified, which §2.2.5 needs.
- Cookies have four parts: two header lines, a file at the browser, a database at the site. The protocol stays stateless; the state lives at the two ends — and the record a site builds can be sold.