HTTP methods, headers, status codes, cookies

02Request, status, and cookie

Start with GET /note HTTP/1.1. GET is the method: it asks the server to send back the content available at that path. /note is the path, which identifies the requested resource on that site. HTTP/1.1 names the protocol version.

The next line, Host: note.lab.invalid, is a header. Headers add details about a message. This one names the site the request is for. In these examples, a header has a name, a colon, and a value.

Now read the response's first line: HTTP/1.1 200 OK. The three-digit number is the status code. Here, 200 means the request succeeded. OK is a short description called the reason phrase. When asked for a numeric status code, read the three digits after the version.

Use the illustration below to follow each line. First identify the browser's request, then the server's response. We will add cookies after separating the rest of the message.

1GET /note HTTP/1.1
2Host: note.lab.invalid
3 

1HTTP/1.1 200 OK
2Content-Type: text/plain
3 
4listed

1GET /note HTTP/1.1
2Host: note.lab.invalid
3 

1HTTP/1.1 200 OK
2Content-Type: text/plain
3 
4listed

03Separate the headers from the body

In the response, Content-Type: text/plain tells the browser how to interpret the content that follows. text/plain means plain text. A Content-Type header can describe a body in a request as well as in a response.

A blank line ends the headers. After that line, listed is the response body: the content delivered in this example. Other response bodies can contain HTML, an image, or other data.

A request can also have a body. For example, a browser can use POST to submit data for the server to process. The activity below shows POST sending the text slip. Compare that with the worked GET request, which has no body.

These examples use ordinary line breaks to show the parts of a message. They leave out some details needed to send it, such as how a receiver knows the body's length. Use them to practice reading HTTP; they are not complete messages to send over a connection.

04How a browser remembers a cookie

A site may need to connect one request with a later request, such as when keeping items in a shopping cart. A cookie is a small name and value that the browser stores and can send back with a later matching request.

The server asks the browser to store a cookie by including a Set-Cookie header in its response. For example, Set-Cookie: cart=blue asks it to store the name cart with the value blue. Browser settings and cookie rules determine whether it is stored and when it is sent.

On a later matching request, the browser can send Cookie: cart=blue. Follow the direction: Set-Cookie travels from server to browser; Cookie travels from browser to server. The matching value lets the server connect the requests.

Some cookies refer to a signed-in session, while others store preferences or cart information. Seeing a cookie alone does not tell you who a person is or whether they may access a resource.

05Read the cookie attributes

Extra settings after the cookie's name and value are called attributes. The activity response includes HttpOnly. This prevents JavaScript running on the page from reading the cookie. The browser can still include it in matching HTTP requests.

Another attribute, Secure, limits sending the cookie to secure connections, normally HTTPS. HttpOnly and Secure have different jobs; a cookie may use both. These settings are part of protecting cookies, and a site still needs appropriate session and access checks.

For this lesson's checks, focus on the header name and the direction of the message. Cookie attributes, same-origin rules, and session security are developed further in later lessons.

06A second response

The worksheet below contains a new POST exchange. Use what you learned from the GET example to read it. Try each step before reading the answer notes at the bottom of the worksheet.

HTTP activity worksheet
Fictional HTTP/1.1 messages, simplified for reading.
The Request and Response labels are not part of HTTP.
The examples omit details needed to send complete messages over a connection.

Request
POST /bin HTTP/1.1
Host: note.lab.invalid
Content-Type: text/plain

slip

Response
HTTP/1.1 201 Created
Content-Type: text/plain
Set-Cookie: lab-sid=note-42; HttpOnly

created

Before reading the answer notes, identify the method, path, response
status, response body, and cookie name and value.

Answer notes
The request uses POST and the path /bin.
The response status is 201. Its body, after the blank line, is created.
Set-Cookie asks the browser to store lab-sid with the value note-42.
HttpOnly is an attribute, separate from that name and value.

1. Find the activity request's first line. Write its method and path, then find the Host header. These identify the action requested and the resource it concerns.
2. Find the activity response's first line. Record the three-digit status code and keep it separate from HTTP/1.1. Here, 201 means the request succeeded and created one or more resources.
3. Locate the blank line in the response. Everything after it, up to the end of that message, is the body. Record the body separately from the headers.
4. Find the header that asks the browser to store a cookie. Write the cookie's name and value, leaving HttpOnly in a separate note as an attribute.
5. Compare your notes with the worksheet: POST requests /bin; the response status is 201; the body is created; and the response asks the browser to store lab-sid with the value note-42.
6. Keep the browser and server directions in mind for the checks below. This activity finishes with reading and note-taking; it requires no network connection.

07Optional challenge

Allow about ten minutes. Assume the browser accepted the activity cookie and is making another request to the same site and path. Write the request header that would return the cookie, then explain why its name differs from the response header.

Check your reasoning: the request uses Cookie: lab-sid=note-42. The earlier response used Set-Cookie to ask for storage. HttpOnly is an attribute on that response header; it is not repeated as part of the cookie value.

08What to remember

Read a message in order: first line, headers, blank line, and body when present. The request method says what action is requested. The response status code reports the result.

Set-Cookie asks the browser to store a cookie; Cookie sends a stored cookie back on a matching request. Next, the HTTPS lesson explains how the connection can protect these messages while they travel.

09Cards for the checks

The checks below use these cards. They are original fictional text, safe to read anywhere.

1HTTP/1.1 503 Service Unavailable
2Content-Type: text/plain
3Retry-After: 120
4 
5queue status: 200 jobs waiting

1HTTP/1.1 201 Created
2Content-Type: text/plain
3Set-Cookie: cart=7; HttpOnly
4Cache-Control: no-store
5 
6added

10Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

1 | POST /parcels HTTP/1.1
2 | Host: parcel.lab.invalid
3 | Content-Type: text/plain
4 |
5 | label=GET /archive

1 | HTTP/1.1 410 Gone
2 | Content-Type: text/plain
3 | X-Queue-Count: 200
4 | Cache-Control: no-store
5 |
6 | queue note: 503 items pending
7 | Content-Type: this is body text

HTTP/1.1 200 OK
Content-Type: text/plain
Set-Cookie: basket=Mint9; HttpOnly
 
saved

For this task: the browser accepts this cookie; it is the only stored cookie.
The next request is to the same HTTPS site and /cart path, before expiry.
Assume all browser settings and cookie matching rules permit sending it.
These simplified reading fixtures omit wire framing details; no request was sent.

11Optional explanation: what did the message establish?

Spend up to five minutes explaining to a partner why a body containing a status-like number cannot replace the response's first line. Then explain which extra assumptions let you predict a cookie's return.

Self-check: identify the response start line, distinguish the blank separator from body content, and describe both cookie directions. Say that a storage request alone does not prove acceptance. This explanation is for your own review; it is not automatically graded.