Headers, body, and content types

Objectives

By the end of the lesson, you can distinguish the headers from the body, you can explain the role of Content-Type and Accept, and you understand why the same service can give a human an HTML page and a program data.

Why do we need headers?

The start line of the request and the response is not enough: it does not say what format the body has, how long the response can be used, who is asking, or in what language. If all such information had to be crammed into the address or the body, the two would get mixed up. HTTP therefore splits the message into two layers: the headers carry additional information about the message, and the body carries the content itself.

The structure of a message

flowchart TB
    K[Start line: method and target, or status code] --> F[Headers: name and value]
    F --> U[Empty line]
    U --> T[Body, if any]

A header is a line of the form name: value; the names are not case-sensitive. (In the HTTP/1.1 outputs it is Content-Type, while HTTP/2 uses lowercase names: content-type.) The body can be the data of a form, a JSON document, HTML, an image, or any file. Not every message has a body: a usual GET request has none, and neither does a 204 No Content response.

Content-Type: what does the body contain?

The Content-Type header says what format the body has. The format is called a media type (formerly MIME type): it has the form type/subtype.

Media type	Meaning
text/html	HTML document
text/plain	plain text
text/css	style sheet
application/json	JSON data
image/png, image/jpeg	images
application/pdf	PDF document

The charset=utf-8 written after it gives the character encoding of the text. The type influences how the client interprets the received bytes: the same text appears as a page if it is HTML, and as source code if it is plain text.

Content-Type is the sender's claim, not a guarantee: the content must actually match it. We also use it in a request when we send a body:

$ curl -i -X POST http://localhost:8080/jelentkezesek \
    -H 'Content-Type: application/json' -d '{"kurzus":"webprog"}'

From this the server knows that it has to interpret JSON. Content-Type is descriptive information, not an authorization: the server still has to check whether the request makes sense and is allowed.

Accept: what response would I like?

The Accept header is sent by the client, and with it signals what format of response it can accept. This is the basis of content negotiation: the same address can be available in several variants. Tried out on the test server:

$ curl -i http://localhost:8080/api/kurzusok -H 'Accept: application/json'
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...
[{"id":"webprog","cim":"Webprogramozás 1.",...}]

$ curl -i http://localhost:8080/api/kurzusok -H 'Accept: text/html'
HTTP/1.1 406 Not Acceptable
Content-Type: text/plain; charset=utf-8
...
Csak JSON érhető el

For the second request the server cannot give a variant that matches the need, so it sends a 406 Not Acceptable response. (The body is Hungarian for "Only JSON is available". Not every server responds this way: many give a default variant they like when the Accept cannot be satisfied.) The two headers are therefore not interchangeable:

Header	Who sends it?	What does it express?
Content-Type	client or server	The format of the sent body
Accept	client	The desired format of the requested response
Location	server	The address of a new or redirected resource

Other headers, other tasks

Headers serve several purposes:

Area	Examples	Where do we discuss it?
Content	Content-Type, Content-Length, Content-Language	this lesson
Routing	Location	the lesson on HTTP status codes in chapter 2
Caching	Cache-Control, ETag	chapter 10
State, identification	Cookie, Set-Cookie, Authorization	chapter 7
Browser security	Content-Security-Policy, Strict-Transport-Security	chapter 8

For now it is enough to know that headers are not the visual "scenery" of the page, but the machine-readable part of how the web works. For many later topics (login, caching, security) headers are the tool.

A page for humans, data for machines

The same web service can give HTML to the browser and JSON to another program. Both are the body of an HTTP response; the difference is signaled by Content-Type. In the network panel (Network) of the browser's developer tools, after clicking, you can see every header and the body of a request; curl -i shows the same from the command line.

Worked example: the course list in two ways

The course list of Kurzuspont can be requested in two ways:

Request	Accept	Response Content-Type	Body
The browser opens the list	text/html	text/html	a page that a human reads
The mobile app fetches the data	application/json	application/json	structured data that a program processes

In chapter 2 this only means that the address and the header together determine what we get. In chapter 5 we will look at the data format and the design of the interface in detail.

Common misconceptions

Statement	Clarification
"A header is the text visible at the top of the page."	An HTTP header is part of the message, not the visual header of the document.
"Content-Type creates the format."	The sender signals the format with it; the content must match.
"Every request has a body."	A usual GET has none.
"Accept and Content-Type are the same."	One describes the requested response, the other the sent body.
"Header names are case-sensitive."	They are not; HTTP/2 uses the lowercase form.

In brief

• Headers are metadata about handling the message, the body is the content.
• Content-Type is the format of the sent body, Accept that of the requested response.
• A media type has the form type/subtype; charset gives the character encoding.
• The same service can serve a human (HTML) and a program (JSON).

Review questions

1. What is the difference between a header and the body?
2. Which header does the client use to signal the desired response format?
3. What can happen if Accept asks for a format that the server cannot give?
4. Why is Content-Type not enough for the security of a request?

Learning resources

• Overview of HTTP (MDN) — the role of headers and the body.
• HTTP Semantics, RFC 9110 — the official description of headers and content negotiation.