HTTP Headers
HTTP Headers let the client and the server pass additional information with an HTTP request or response. It consists of its case-insensitive name followed by a colon (:
), then by its value.
We can make a distinction between Standardized and Unstandardized/Custom Headers.
Headers can be grouped according to their contexts:
- General
- Request
- Response
- Entity
And also by how proxy servers handle them:
- End-to-End
- Hop-by-Hop
You can check the list of all HTTP headers here.
General Headers
Apply to both request and responses, but with no relation to the data transmitted in the body.
Most common are:
Date
Cache-Control
Connection
Request Headers
Contain more information about the resource to be fetched, or about the client requesting the resource.
Not all headers appearing in a request are request headers. For example, the Content-Length
appearing in a POST
request is actually an Entity Header referring to the size of the body of the request message. However, these Entity headers are often called Request Headers in such a context.
Most common are:
Authorization
: Used for basic auth pages mainly.Accept
,Accept-*
: Indicates what MIME type(s) are accepted by the client.If-*
: Makes the request conditinoal based on provided condition.Cookie
: Passes cookie data to the server.User-Agent
: Lets servers and network peers identify the application, os, vendor, and/or version of the requesting User Agent.Host
: Indicates the desired host handling the request.Referer
: Page leading to this request (this is not passed to other servers when using HTTPS on the origin)
Response Headers
Hold additional information/context about the response, like its location or about the server providing it.
Most common are:
Age
Location
Server
Entity Headers
Contain information about the body of the resource, like its content length or MIME Type.
Most common are:
Content-Language
Content-Length
Content-Encoding
End-to-End Headers
These headers must be transmitted to the final recipient of the message: the server for a request or the client for a response. Intermediate proxies must retransmit these headers unmodified and caches must store them.
Hop-by-Hop Headers
These headers are meaningful only for a single transport-level connection, and must not be retransmitted by proxies or cached.
Note that only Hop-by-Hop Headers may be set using the Connection
General Header.
Custom Headers
Custom Headers can be used to whatever application specif use you may need, you can use any name for the header you want even though it's not part of HTTP standard.
Historically, unstandarized parameters have been prefixed with the string X-
or similar constructs. It has been deprecated in 2002, RFC-6648 and new recomendations regarding this topics had been given.
The main reason for deprecation is that when non-standard headers prefixed with X-
become standard, removing the prefix breaks backwards compatibility, foring application protocls to support both names.
The recommendation basicaly is to just name our custom headers sensibly without the prefix.