Anatomy of a Request and Response

The response the server sends back has the same four parts. Only the first line is different:

• The status line replaces the request line. It includes the HTTP version, a status code, and a short reason phrase. HTTP/1.1 200 OK means "I am using HTTP 1.1, and your request succeeded." We will cover status codes in detail shortly.
• The headers describe the response and the body attached to it. In this example, Content-Type says the body is HTML, and Content-Length says it is 38 bytes long.
• The blank line separates the headers from the body, exactly as it does in the request.
• The body is the actual content. In this case, it is the HTML page.

This mirror image is a helpful concept to remember. The request and the response use the same basic envelope. The first line simply changes from "here is what I want" to "here is how it went."

Why the blank line matters

A single empty line is easy to overlook, but it is a vital part of the message. It acts as a marker that tells the receiver, "the headers are finished; everything after this is the body."

The receiver reads headers one line at a time until it hits an empty line. At that point, it stops looking for headers and treats the rest of the message as the body. Without this separator, there would be no way to tell where the metadata ends and the content begins. It is a small rule that the entire format relies on.

How the client knows when the body ends

Reaching the body raises a fair question. How does the receiver know when the body stops? The network connection might stay open for the next request, so the client cannot just read until the connection closes. There are two common ways to handle this.

The first is the Content-Length header. This header states the exact size of the body in bytes, just like in the response example above. The receiver reads precisely that many bytes and knows it is finished.

The second is chunked transfer. Sometimes the server does not know the total size up front, perhaps because it is generating the response on the fly. In this case, it sends Transfer-Encoding: chunked and streams the body in labeled pieces. Each piece is prefixed with its own length. The transmission ends with a zero-length chunk that signals the end of the message. You do not need to memorize the details right now. Just know that a body without a Content-Length is usually arriving in chunks.

The body is just bytes

There is one last idea that makes HTTP easy to understand. The body has no fixed type. It is simply a sequence of bytes. The Content-Type header is what tells the client how to interpret those bytes. Change that header, and the exact same response shape carries something completely different.

If the Content-Type is text/html, the browser renders a web page. Change it to application/json, and the body becomes data for your code to parse. Change it to image/png, and the bytes become a picture. The envelope never changes. Only the label and the bytes inside change. This flexibility is why one protocol can carry the entire web.

Try it now

You can use curl with the verbose flag to see both halves of a real exchange:

Lines that start with > represent the request that curl sent. Lines that start with < represent the response that came back. You will spot the request line, the headers, and the status line right away.

If you want to see just the response, running curl -i prints the status line, the headers, the blank line, and the body together. This lets you see the four parts stacked exactly as described above.

What's Next

The request line opens with a single word called the method. This method decides what the server should do. The next chapter works through GET, POST, and the other common methods, along with the rules that keep them predictable.