الترويسات (Headers)

Written Explanation

Shape of a header

A header is one line: a name, a colon, a value.

Content-Type: application/json

MDN states that header names are case-insensitive, so content-type and Content-Type mean the same thing. A request or response may have many headers, one per line. Their order mostly does not matter.

Headers fall into rough groups. Request headers give context about the request (Host, Accept, Authorization). Response headers give context about the response (Date, Server, Cache-Control). Representation headers, such as Content-Type and Content-Length, describe the body and appear in both directions.

The headers you will see most

I verified Host, Content-Type, Content-Length, Accept, Authorization, Date, Cache-Control, and Location in MDN's pages; the direction and one-line descriptions of Cookie and Set-Cookie follow MDN's statement that cookies enable stateful sessions, and the exact header names are standard HTTP.

Content-Type and Accept: two sides of format

• Content-Type describes the body that this message carries. A request that sends a book as JSON says Content-Type: application/json. A response that returns HTML says Content-Type: text/html.
• Accept says what the client would like to receive. Accept: application/json means "please answer in JSON".

Restaurant version: Accept is "I would like the menu in French"; Content-Type on the dish's note is "this note is written in French". The pair lets the client and server agree on a format, which MDN calls content negotiation. If you forget Content-Type on a request that carries JSON, the server may not know how to read it and can answer 415 Unsupported Media Type, the code for exactly that situation.

The value application/json is a media type: a category (application, text, image) and a specific kind (json, html, png) separated by a slash. Sometimes a parameter follows, such as application/json; charset=utf-8.

Authorization: credentials

Authorization carries what proves who you are. Per MDN, the usual flow is: the client asks for a protected resource without credentials, the server answers 401, and the client tries again with an Authorization header such as:

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

With Basic, the credentials are a username and password joined by a colon and then Base64-encoded. Base64 is a way of writing bytes as text; it is not encryption. MDN warns that it is trivially reversible and recommends HTTPS, especially with Basic. Another common scheme, Bearer, sends a token instead of a password: Authorization: Bearer <token>. (MDN's Authorization page does not document Bearer; it is standardized elsewhere, in RFC 6750, which I did not open for this lesson.)

Treat this header like a password. Never paste it into chat, a screenshot, or a ticket. In BEG-003 you learned why HTTPS protects such headers in transit: without it, anyone along the path could read them.

Headers in a conversation

POST /books HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>

{"title":"Dune"}

A server can read this as: "this is for api.example.com, I am sending JSON, I want JSON back, and here is my proof of identity." The matching response might add Content-Type: application/json, a Date, and Location: /books/8 pointing to the new item.

Who writes the headers?

Most of the time not you. A browser adds Host, Accept, Cookie, and others by itself, and a server framework adds Date and Content-Length. You set a header yourself when it carries a decision of yours: the Content-Type of the data you return, a Location for a created item, an Authorization token in a script that calls an API, or Cache-Control when you want to control reuse. Headers can also be custom: an application may invent its own names for its own purposes, and the receiver simply ignores names it does not know. This extensibility is what lets cookies and authentication sit on top of plain HTTP without changing the protocol.