HTTP Header Fields

HTTP Header Fields

Fields of the HTTP header provide the required information about the request or response, or the object sent in the message body. There are four types of headers for HTTP messages:

• General-header: These header fields are generally applicable for both request messages and responses.
• Client Request-header: These header fields only apply to request messages.
• Server Response-header: These header fields are applicable for reply messages only.
• Entity-header: These header fields define meta information about the entity-body, or the resource identified by the request, if there is no body present.

General Headers

Cache-Control

The general-header field Cache-Control is used to specify directives that all of the caching system MUST obey. The syntax consists of:

Cache-Control : cache-request-directive|cache-response-directive

An HTTP client or server may use the general header Cache-control to specify cache parameters or request certain kinds of cache documents. The directives for caching are positioned in a comma-separated list. Take , for example:

Cache-control: no-cache

The following table lists the important directives for cache requests that the client can use in its HTTP request:

Sr No	Cache Request Directive and Description
1.	no-cache A cache must not use the response to satisfy a subsequent request with the origin server without successful revalidation.
2.	no-store Nothing about the client request or the server response should be processed in the cache.
3.	max-age = seconds Indicates the client's willingness to accept a response whose age in seconds is no greater than the time specified.
4.	max-stale [ = seconds ] Indicates that the client is prepared to accept a response that has exceeded its expiry time. If seconds are given, then more than that time must not expire.
5.	min-fresh = seconds Indicates that the client is willing to accept a response whose lifetime of freshness is not less than its current age plus the time in seconds specified.
6.	no-transform Does not convert the entity-body.
7.	only-if-cached Retrieves no new data. The cache can only send a document when it is in the cache, and should not contact the origin-server to see if there is a newer copy.

The following important cache response directives that the server can use in its response to HTTP are:

Sr No	Cache Response Directive and Description
1.	public Indicates that every cache can cache the response.
2.	private Specifies that all or part of the response message is intended for a single user and should not be cached by a shared cache;
3.	no-cache A cache must not use the answer to satisfy a subsequent request with the origin server without successful re-validation.
4.	no-store Nothing about the client request or the server response should be processed in the cache.
5.	no-transform Does not convert the entity-body.
6.	must-revalidate Before using it, the cache must verify the status of the stale documents, and should not use expired documents.
7.	proxy-revalidate The proxy-revalidate directive has the same meaning as the must- revalidate directive, except that it does not apply to non-shared user agent caches.
8.	max-age = seconds Indicates the client's willingness to accept a response whose age in seconds is no greater than the time specified.
9.	s-maxage = seconds The maximum age specified by this directive overrides the maximum age specified by either the Expires header or the max-age directive. A private cache always ignores the s-maxage Directive.

Connection

The general-header Connection field allows the sender to specify options which are desired for that particular Connection and which are not to be communicated by proxies over further Connection. A simple syntax for the use of the Connection header follows:

Connection : "Connection"

HTTP/1.1 defines the sender's "close" connection option to signal the connection will be closed once the response is complete. Take , for example:

Connection: close

HTTP 1.1 uses persistent connections by default, where the connections does not close automatically after a transaction. In contrast, HTTP 1.0, by default, does not have persistent connections. If a 1.0 client wants to use persistent connections it will use the parameter keep-alive as follows:

Connection: keep-alive

Date

Without exception all HTTP date / time stamps MUST be represented in Greenwich Mean Time (GMT). HTTP applications may use any of the following three Date / Time stamp representations:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Pragma

The general-header field of Pragma is used to include specific directives for implementation that may apply to any recipient along the request / response chain. Take , for example:

Pragma: no-cache

The only directive defined in HTTP/1.0 is the no-cache directive, and the backward compatibility is maintained in HTTP 1.1. There will be no new directives on Pragma defined in the future.

Trailer

The general field value for the Trailer indicates that the given set of header fields is present in a message trailer encoded with chunked transfer-coding. The syntax for Trailer header field follows:

Trailer : field-name

Message header fields listed in the Trailer header field must not include:

• Transfer-Encoding
• Content-Length
• Trailer

Transfer-Encoding

The General-header Transfer-Encoding field indicates what type of transformation was applied to the message body in order to transfer it safely between the sender and the receiver. This isn't the same as content encoding because transfer-encoding is a message property, not an entity-body property. The Transfer-Encoding field header syntax is as follows:

Transfer-Encoding: chunked

All transfer-coding values are case-insensitive.

Upgrade

The General-header upgrade allows the client to specify what additional communication protocols it supports and would like to use if the server finds that switching protocols is appropriate. Take , for example:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other protocol which is incompatible.

Via

Gateways and proxies must use the Via general-header to indicate the intermediate protocols and receivers. For example, a request message could be sent to an internal proxy code-named "fred" from an HTTP/1.0 user agent, using HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu.

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

The Upgrade header field is designed to provide a simple transition mechanism from HTTP/1.1 to another, incompatible protocol.

Warning

The General-header Warning is used to carry additional information on the status or transformation of a message that may not be reflected in the message. A response can carry more than one Header of Warning.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Client Request Headers

Accept

The field Accept request-header can be used to specify certain types of media which are acceptable to the response. The syntax generally is as follows:

Accept: type/subtype [q=qvalue]

Multiple media types can be listed separately by commas and the optional qvalue is an acceptable level of quality for accepting types on a scale of 0 to 1 Below is an example:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

This would be interpreted as text / html and text / x-c and are the preferred media types, but if they do not exist, then send the text / x-dvi entity, and send the text / plain entity if that does not exist.

Accept-Charset

The request-header field for Accept-Charset can be used to specify which character sets are acceptable for the response. The General Syntax follows:

Accept-Charset: character_set [q=qvalue]

It is possible to list multiple character sets separated by commas and the optional qvalue represents an acceptable quality level for non-preferred character sets on a scale of 0 to 1. Below is an example:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

When present in the Accept-Charset field, the special value "*" matches every set of characters and if there is no Accept-Charset header present, the default is that any set of characters is acceptable.

Accept-Encoding

The request-header field Accept-Encoding is similar to Accept, but restricts the content-codes acceptable in the response. The syntax generally is:

Accept-Encoding: encoding types

Examples are as follows:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

The field Accept-Language request-header is similar to Accept, but restricts the set of natural languages preferred as an answer to the request. The syntax generally is:

Accept-Language: language [q=qvalue]

You can list multiple languages separated by commas and the optional qvalue represents an acceptable level of quality for non-preferred languages on a scale of 0 to

1. Below is an example:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Authorization

The Authorization request-header field value is composed of credentials containing the user agent's authentication information for the realm of the resource requested. The syntax generally is:

Authorization : credentials

The HTTP/1.0 specification defines the BASIC authorization scheme, where the parameter for authorization is the string of username: password encoded in base 64. Below is an example:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

The value decodes into is guest:guest123 where guest is user ID and guest123 is the password.

Cookie

The field value of the Cookie request-header contains a name / value pair of information which is stored for that URL. The General Syntax follows:

Cookie: name=value

Separated by semicolons multiple cookies can be specified as follows:

Cookie: name1=value1;name2=value2;name3=value3

Expect

The Expect request-header field is used to indicate the client is requiring a specific set of server behaviours. The syntax generally is:

Expect : 100-continue | expectation-extension

If a server receives a request that contains an Expect field that includes an Expect-extension that it does not support, it must respond with a status of 417 (Expectation Failed).

From

The field From request-header contains an e-mail address for the human user who controls the requesting user agent on the Internet. Then there is a simple example:

From: webmaster@w3.org

This field header can be used for logging purposes and as a way to identify the source of invalid or unwanted requests.

Host

The field Host request-header is used to specify the Internet host and the resource port number being requested. The syntax generally is:

Host : "Host" ":" host [ ":" port ] ;

A host without any information about trailing port implies the default port, which is 80. For instance a request for http:/www.w3.org/pub/WWW/ on the origin server would be:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

The field If-Match request-header is used for making it conditional with a method. This header requests that the server perform the requested method only if the value given in this tag matches the tags of the given entity represented by ETag. The syntax generally is:

If-Match : entity-tag

An asterisk (*) matches any entity, and only if the entity exists, does the transaction continue. Possible examples below are:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

If none of the entity tags match, or if "*" is given and there is no current entity, the server must not perform the requested method and must return a response of 412 (Failed condition).

If-Modified-Since

The field If-Modified-Since request-header is used for making it conditional by a method. If, since the time specified in this field, the requested URL has not been modified, an entity will not be returned from the server; instead, a response of 304 (not modified) will be returned without any message-body. If-modified-since's

General Syntax is:

If-Modified-Since : HTTP-date

An example of the field is:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If none of the entity tags match, or if "*" is given and no current entity exists, the server must not perform the method requested and must return a response of 412 (Failed Precondition).

If-None-Match

The request-header field If-None-Match is used with a method to make it conditional. This header asks the server to perform the requested method only if one of the values given in this tag matches the tags of the given entity represented by ETag. The syntax generally is:

If-None-Match : entity-tag

An asterisk (*) matches any entity, and only if the entity doesn't exist will the transaction continue. Below are the possible examples:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

The If-Range request-header field can be used with a conditional GET to request only the missing portion of the entity if it has not been changed, and the whole entity if changed. The general syntax would be as follows:

If-Range : entity-tag | HTTP-date

Either a tag of the entity or a date can be used to identify the already received partial entity. Take , for example:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Here the server returns the byte range given by the Range header if the document has not been modified since the date given, otherwise it returns all of the new document.

If-Unmodified-Since

The field If-Unmodified-Since request-header is used for making it conditional by a method. The syntax generally is:

If-Unmodified-Since : HTTP-date

If, since the time specified in this field, the requested resource has not been changed, the server should perform the requested operation as if the If-Unmodified-Since header were not present. Take , for example:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

The If-Unmodified-Since header should be ignored when the request results in anything other than a 2xx or 412 status.

Max-Forwards

With the TRACE and OPTIONS methods, the Max-Forwards request-header field provides a mechanism to limit the number of proxies or gateways that can forward the request to the next inbound server. The general syntax is:

Max-Forwards : n

The value of Max-Forwards is a decimal integer which indicates the remaining number of times that request message may be forwarded. This is useful to debug using the TRACE method, to avoid infinite loops. Take , for example:

Max-Forwards : 5

For all other methods defined in the HTTP specification the Max-Forwards header field may be ignored.

Proxy-Authorization

The request-header field Proxy-Authorization allows the client to identify themselves (or their user) to a proxy that requires authentication. The general syntax is:

Proxy-Authorization : credentials

The Field Value of Proxy-Authorization consists of credentials containing the user agent's authentication information for the proxy and/or realm of the resource required.

Range

The field Range request-header specifies the partial range(s) of the content that the document requests from it. The syntax generally is:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

In a byte-range-spec the first-byte-pos value gives the byte-offset of the first byte in a range. The value of the last byte-pos gives the byte-offset of the last byte in the range; that is, the specified byte positions are inclusive. You can specify as bytes a Byte-unit. Byte offsets commence at zero. Below are some simple examples:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Referer

The field Referer request-header allows the client to specify the resource address (URI) from which the URL was requested. The general syntax consists of:

Referer : absoluteURI | relativeURI

Following is a simple example:

Referer: http://www.phptpoint.com/http-tutorial/

If the field value is a relative URI, the Request-URI should be interpreted as related.

TE

The TE request-header field indicates which extension transfer-coding you are prepared to accept in the response and whether or not you are willing to accept trailer fields in a chunked transfer-coding. Then there is the general syntax:

TE   : t-codings

The presence of the keyword "trailers" indicates the client's willingness to accept trailer fields in a chunked transfer-coding, and either way is specified:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

If the TE field-value is empty or if there is no TE field, then only the transfer-coding will be chunked. An transfer-coded message is always acceptable.

User-Agent

The request-header field for the User-Agent contains information about the user agent which originated the request. The General Syntax follows:

User-Agent : product | comment

Example:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Server Response Headers

Accept-Ranges

The response-header field Accept-Ranges allows the server to indicate their acceptance of a resource 's range requests. The syntax generally is:

Accept-Ranges  : range-unit | none

For example, a server which accepts requests for byte ranges may send:

Accept-Ranges: bytes

Servers which do not accept any kind of resource range request may send:

Accept-Ranges: none

This will advise customers not to attempt a request for a range.

Age

The Age response-header field conveys an estimate of the amount of time the sender has had since the response (or its revalidation) was generated on the origin server. Common syntax is:

Age : delta-seconds

Age values, representing time in seconds, are non-negative decimal integer. Then there is a simple example:

Age: 1030

An HTTP/1.1 server which includes a cache must include an Age header field in each response generated from the cache itself.

ETag

The response-header field on the ETag provides the entity tag's current value for the requested variant. The syntax generally is:

ETag :  entity-tag

Here are some simple examples:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Location

The response-header field of Location is used to redirect the receiver to a location other than the Request-URI for completion. The syntax generally is:

Location : absoluteURI

Following is a simple example:

Location: http://www.phptpoint.com/http-tutorial/

The header field Content-Location differs from Location in that the Content-Location identifies the original location of the entity included in the request.

Proxy-Authenticate

The response-header field Proxy-Authenticate must be included as part of a response 407 (Proxy Authentication Required). The syntax generally is:

Proxy-Authenticate  : challenge

Retry-After

The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the requesting customer expects the service to be unavailable. Common syntax is:

Retry-After : HTTP-date | delta-seconds

Examples:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

In the latter example, the delay is 2 minutes.

Server

The response-header field of the Server contains information about the software used by the server of origin to handle the request. The syntax generally is:

Server : product | comment

Following is a simple example:

Server: Apache/2.2.14 (Win32)

If the response is forwarded via a proxy, the server response header must not be modified by the proxy application.

Set-Cookie

The response-header field Set-Cookie contains a pair of names / values of information to retain for this URL. The syntax generally is:

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie response header includes the Set-Cookie token, followed by a comma-separated list of one or several cookies. Here are the values which you can specify as options:

Sr No	Options and Description
1.	Comment=comment You can use this option to specify any comments associated with the cookie.
2.	Domain=domain The Domain attribute specifies the domain the cookie is valid for.
3.	Expires=Date-time The cookie date will expire. The cookie expires when the visitor quits the browser when it is blank.
4.	Path=path The Path attribute specifies the subset of URLs applied to by this cookie.
5.	Secure The user agent is instructed to return the cookie only under a secure connection.

Following is an example of a simple cookie header generated by the server:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

The Vary response-header field specifies that the entity has multiple sources and can therefore vary according to the request header(s) list specified. The General Syntax follows:

Vary : field-name

You can specify multiple headers separated by commas and a value of "*" asterisk signals that the request headers are not limited to unspecified parameters. This is just one simple example:

Vary: Accept-Language, Accept-Encoding

Here field names are case-insensitive

Expires

The field Expires entity-header gives the date / time after which the answer is deemed stale. The syntax generally is:

Expires : HTTP-date

Following is an example:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

The field Last-Modified entity-header indicates the date and time at which the origin server believes that the variant has been last modified. The syntax generally is:

Last-Modified: HTTP-date

Following is an example:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT