HTTP headers

This article provides general information about HTTP headers.
For a description of specific headers, see List of HTTP Headers .

HTTP headers ( HTTP Headers ) are strings in an HTTP message that contain a colon separated by a colon name / value. The header format follows the general ARPA text messaging header format (see RFC 822 ). The headers must be separated from the body of the message by at least one blank line.

All headings are divided into four main groups:

General Headers ( Russian. Main headers ) - must be included in any message from the client and server.
Request Headers ( Russian. Request headers ) - are used only in client requests.
Response Headers ( rus. Response headers ) - only for responses from the server.
Entity Headers ( Rus. Entity Headers ) - accompany each entity of the message.

It is in this order that it is recommended to send headers to the recipient.

Content

General format

The parameter name must consist of at least one printed character ( ASCII codes from 33 to 126). The case of characters in the names does not matter. Headings with unknown names should be ignored. A colon symbol immediately follows the name.
The value can contain any ASCII characters except line feed (code 10) and carriage return (code 13). Whitespace at the beginning and end of a value is truncated. The sequence of several whitespace characters within a value can be interpreted as one space. The case of characters is also irrelevant (unless otherwise provided by the field format).

It is planned to place the value on several lines (line break). To indicate hyphenation, at least one white space must be at the beginning of the next line.

Headings with the same parameter names but with different values can be combined into one only if the field value is a comma-separated list. In all other cases, the values of the farther headers should overlap the previous ones. Therefore, proxies should not change the order of the headers in the message. In this case, the order of the list items usually does not matter.

An example with multi-line values and the same header names (note the case of characters and spaces):

  content-type: text / html;
               charset = windows-1251
 Allow: GET, HEAD
 Content-Length: 356
 ALLOW: GET, OPTIONS
 Content-Length: 1984

The correct compact version of the conversion and interpretation:

  Content-Type: text / html; charset = windows-1251
 Allow: GET, HEAD, OPTIONS
 Content-Length: 1984

In this case, it is unacceptable to accept a Content-Length value of 356. When combining Allow values, in order not to lose semantic meaning, a comma was added to the end of the first field and the meaninglessly duplicated GET element was removed.

Headings Used

Date and Time

Only the date is indicated in the Date , Expires , Last-Modified , If-Modified-Since , If-Unmodified-Since headers. The date may appear in the If-Range and Warning headers.

HTTP uses three formats:

Fri, 04 Jul 2008 08:42:36 GMT - the preferred format for RFC 7231 , a subset of the format for RFC 5322 .
Friday, 04-Jul-08 08:42:36 GMT - the format described in the obsolete RFC 850 .
Fri Jul 4 08:42:36 2008 - the result of the asctime () function of ANSI C.

RFC 7231 requires data recipients to be prepared to process date and time stamps in all three formats, and to generate date and time stamps only in their preferred format.

Time is always indicated for the GMT time zone ( UTC + 0 ). The year is written in four digits. Day, hour, minute, and second are padded with zeros to two characters. Three-letter standard abbreviations in English are used for the names of the month and day of the week.

Days of the week starting from Monday: Mon , Tue , Wed , Thu , Fri , Sat , Sun

Months from January to December: Jan , Feb , Mar , Apr , May , Jun , Jul , Aug , Sep , Oct , Nov , Dec

In PHP , the gmdate () function is used to convert local time during GMT. Examples of generating dates for HTTP headers:

  // Current date of document formation:
  header ( "Date:" . gmdate ( DateTime :: RFC850 ));

  // Modified date of the specified file:
  $ fp = 'data / my-foo.txt' ;  // the path to the file
  header ( "Last-Modified:" . gmdate ( "D, d MYH: i: s" , filemtime ( $ fp )) . "GMT" );

  // The document is supposed to change in an hour:
  header ( "Expires:" . gmdate ( "D, d MYH: i: s" , time () + 3600 ) . "GMT" );
  // 3600 - number of seconds relative to the current moment.

Byte ranges

When working with content fragments in special headers, byte ranges are used. In them, you can specify both a single fragment and several separating them with commas “ , ”. Ranges are used in the Range and Content-Range headers. The Accept-Ranges header lists only units.

In byte ranges, the name of the unit of measure is mandatory at the beginning, followed by the symbol “ = ”. Currently, apart from bytes units, no others are applied. Beyond the “ = ” symbol are the ranges themselves. Each of them is separated by a hyphen “ - ” a pair of natural numbers or zero and a natural number. The first element indicates the start byte, and the second indicates the end byte. Numbering in ranges starts from zero.

The start or end byte may not be specified. In the absence of the last byte, it is considered that we are talking about a fragment from the initial byte to the end of the content. If there is no beginning, then the end byte number is taken as the number of requested bytes from the end of the content.

If the first byte is larger than the last, then the range is considered syntactically invalid . Header fields containing ranges with syntactically invalid values are ignored. If the first byte is out of the resource, then the range is ignored. If the last byte goes beyond the content, then the range is truncated to the end.

A block of byte ranges is considered feasible if it contains at least one available range. If all the ranges are incorrect or go beyond the resource, then the server should return a message with the status 416 (Requested range not satisfiable).

Examples (the entire resource is 5000 bytes):

bytes=0-255 - a fragment from the 0th to the 255th byte inclusive.
bytes=42-42 - request for one 42nd byte.
bytes=4000-7499,1000-2999 - two fragments. Since the first goes beyond, it is interpreted as " 4000-4999 ."
bytes=3000-,6000-8055 - the first is interpreted as " 3000-4999 ", and the second is ignored.
bytes=-400,-9000 - the last 400 bytes (from 4600 to 4999), and the second is adjusted to the content framework (from 0 to 4999), designating the entire volume as a fragment.
bytes=500-799,600-1023,800-849 - at intersections, ranges can be combined into one (from 500 to 1023).

Work with headers

HTML Headers

HTML markup language allows you to set the necessary values for HTTP headers inside <HEAD> using the <META> . In this case, the title of the header is indicated in the http-equiv attribute, and the value is specified in content . The value of the Content-Type header with the encoding is almost always set to avoid problems with the display of text by the browser. Also, specifying the value of the Content-Language header is not superfluous:

  < html >
 < head >
 < meta http-equiv = "Content-Type" content = "text / html; charset = windows-1251" >
 < meta http-equiv = "Content-Language" content = "en" >
 ...