HTTP Поля заголовка. Правильные HTTP заголовки. Готовим почву для SEO на этапе разработки

Привет, читатель блога сайт! Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе . В данной публикации вы найдете все поля HTTP заголовков их описание и небольшие примеры. Возможно, в этой рубрике появится более подробные публикации про каждую из групп полей заголовка, пока я советую обратиться вам к официальной документации .

Поля HTTP заголовков запроса пользователя

Ниже приведены поля HTTP заголовка запроса пользователя , это те поля, которые могут быть использованы в . Обратите внимание на то, что в данной таблицы сведены поля HTTP заголовков при запросе и служебные поля HTTP заголовков запроса. Так же для удобства в справочнике поля заголовков HTTP запроса упорядочены в алфавитном порядке. В таблице будут приведены сначала служебные поля заголовка запроса, а затем поля заголовка объекта.

Поля HTTP заголовка	Описание поля HTTP заголовка	Пример
Accept	Поле заголовка запроса Accept используется, чтобы определить тип информации, который должен содержаться в ответе	Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c
Accept-Charset	Поле заголовка запроса Accept-Charset указывает на , которая должна быть в ответе сервера. Другими словами: данное поле указывает на то, какие наборы символов приемлемы для ответов сервера	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Encoding	Поле заголовка запроса Accept-Encoding указывает серверу на то, какие способы кодирования приемлемы для ответа.	Accept-Encoding: compress, gzip
Accept-Language	Поле заголовка запроса Accept-Language указывает серверу приемлемые языки (естественные языки: русский, китайский, английский и пр.)	Accept-Language: da, en-gb;q=0.8, en;q=0.7
Authorization	Поле заголовка запроса Authorization используется для отправки данных авторизации на сервер	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Disposition	Поле заголовка запроса Content-Disposition используется для сохранения файлов на сервере	Content-Disposition: form-data; name="MessageTitle" Content-Disposition: form-data; name="AttachedFile1"; filename="photo-1.jpg"
Expect	Поле заголовка запроса Expect позволяет клиенту задать поведение сервера, например, при помощи данного поля клиент может сообщить серверу, что ожидает от него дальнейших действий.	Expect: 100-continue
From	Поле заголовка запроса From служит для передачи серверу адреса электронной почты клиента	From: [email protected]
Host	Поле заголовка запроса Hostиспользуется для указания доменного имени и порта запрашиваемого ресурса.	Host: сайт
If-Match	Поле заголовка запроса If-Match используется клиентом для эффективного обновления кэшируемой информации. В данном поле передается список тегов версий сущности (HTTP объекта)	If-Match: «xyzzy» If-Match: «xyzzy», «r2d2xxxx», «c3piozzzz» If-Match: *
If-Modified-Since	Поле заголовка запроса If-Modified-Since указывает на то, что сервер должен отправить объект, если он изменился с даты, указанной в заголовке.	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match	Поле заголовка запроса If-None-Match выполняется клиентом, у которого есть один или более объектов, ранее полученных из ресурса, может проверить, что ни один из тех объектов не является текущим, включая список их связанных тэгов объекта в поле заголовка If-None-Match	If-None-Match: «xyzzy» If-None-Match: W/"xyzzy" If-None-Match: «xyzzy», «r2d2xxxx», «c3piozzzz» If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: *
If-Range	Поле заголовка запроса If-Range используется клиентом в том случае, когда он имеет частичную копию объекта в его кэше, и желает иметь современную копию всего объекта	If-Range: «737060cd8c284d8af7ad3082f209582d»
If-Unmodified-Since	Поле заголовка запроса If-Unmodified-Since используется клиентом если если запрошенный ресурс не был изменен со времени, указанного в этом поле.	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Words	Поле заголовка запроса Max-Words используется , чтобы ограничить число прокси-серверов, иначе может получиться бесконечный цикл.	Max-Forwards: 10
Proxy-Authorization	Поле заголовка запроса Proxy-Authorization содержит в себе информацию для авторизации на прокси-сервере	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	Поле заголовка запроса Range указывает фрагмента ресурса, который требуется клиенту, чтобы не тянуть весь ресурс целиком	Range: bytes=50000-99999,250000-399999,500000-
Referer	Поле заголовка запроса Referer содержит в себе URI ресурса (читай про ), с которого клиент перешел на данный ресурс	Referer: http://сайт
TE	Поле заголовка запроса TE содержит список расширенных способов кодирования, поддерживаемых клиентом, для передачи.	TE: deflate TE: trailers, deflate;q=0.5
User-Agent	Поле заголовка запроса User-Agent содержит в себе полную информацию о клиенте пользователя, например, о браузере.	User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Content-Encoding	Поле заголовка запроса Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия	Content-Encoding: gzip
Content-Language	Поле заголовка запроса Content-Language указывает серверу на каком языке нужна информация (), находящаяся в теле объекта.	Content-Language: mi, en
Content-Length	Поле заголовка запроса Content-Length указывает необходимую длину тела сообщения в байтах	Content-Length: 3495
Content-Location	Поле заголовка запроса Content-Location используется для идентификации исходного местоположения объекта на сервере.	«Content-Location» «:» (absoluteURI \| relativeURI)
Content-MD5	Поле заголовка запроса Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения.
Content-Range	Поле заголовка запроса Content-Range используется в том случае, когда клиент запрашивает фрагмент . Данное поле имеет значение
Content-Type	Поле заголовка запроса Content-Type используется для указания в теле сообщения.
Content-Version	Поле заголовка запроса Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется)
Derived-From	Поле заголовка запроса Derived-From это аналог Content-Version (обычно не реализуется)
Expires	Поле заголовка запроса Expires содержит того момента, когда информация HTTP объекта перестанет быть актуальной
Last-Modified	Поле заголовка запроса Last-Modified содержит дату последней модификации HTTP объекта
Link	Поле заголовка запроса Link указывает на логически связный с сущностью ресурс (обычно не реализуетсяя)
Title	Поле заголовка запроса Title содержит заголовок объекта

Поля HTTP заголовка ответа сервера

Ниже в таблицы приведены поля HTTP заголовка ответа сервера . Поля HTTP заголовка ответа сервера – это те поля, которые могут быть использованы в сервера на запросы клиента. Обратите внимание на то, что таблица содержит не только служебные поля заголовка ответа, но и поля заголовка HTTP объекта при ответе сервера.Сначала в таблицы идут служебные поля заголовка HTTP ответа, а затем поля заголовка HTTP объекта при ответе сервера. Справочник полей HTTP заголовка ответов сервера упорядочен в алфавитном порядке.

Поля HTTP заголовка	Описание поля HTTP заголовка	Пример
Accept-Ranges	Поле заголовка ответа Accept-Ranges. Этим полем сервер сообщает клиенту о том, в каких единицах измерения тот может запрашивать фрагменты объекта	Accept-Ranges: bytes Accept-Ranges: none
Age	Поле заголовка ответа Age хранит в себе количество секунд с момента последней модификации ресурса
Alternates	Поле заголовка ответа Alternates указывает на альтернативные способы представления ресурса и обычно не реализуется серверами.
Content-Disposition	Поле заголовка ответа Content-Disposition используется для сохранения файлов на
ETag	Поле заголовка ответа ETag идентифицирует	ETag: «56d-9989200-1132c580»
Location	Поле заголовка ответа Location указывает URI, на котором хранится запрошенный ресурс	Location:absoluteURI
Proxy-Authenticate	Поле заголовка ответа Proxy-Authenticate содержит в себе информацию о параметрах	Proxy-Authenticate:challenge
Public	Поле заголовка ответа Public содержит в себе список доступных методов (читай про ) для всего HTTP сервера	Public: OPTIONS, MGET, MHEAD, GET, HEAD
Retry-After	Поле заголовка ответа Retry-After обычно используется сервером вместе с кодом состояния 503 () и указывает на то, как долго ресурс будет недоступен	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120
Server	Поле заголовка ответа Server содержит в себе необходимую информацию о сервере для установления	Server: /2.2.17 (Win32) PHP/5.3.5
Vary	Поле заголовка ответа Vary указывает клиенту на то, что HTTP объект имеет несколько источников и его содержимое может изменяться в зависимости от выбранного источника, указанного в URI	Vary: Accept-Language, Accept-Encoding
WWW-Authenticate	Поле заголовка ответа WWW-Authenticate используется сервером вместе с 401 (). В данному поле указываются схемы аутентификации и требуемые параметры для доступа к ресурсу	WWW-Authenticate = «WWW-Authenticate» «:» 1#challenge
Allow	Поле заголовка ответа Allow передает клиенту методы, которые тот может использовать	Allow: GET, HEAD, PUT
Content-Encoding	Поле заголовка ответа Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия	Content-Encoding: gzip
Content-Language	Поле заголовка ответа Content-Language указывает клиенту на каком языке информация, находящаяся в теле объекта.	Content-Language: mi, en
Content-Length	Поле заголовка ответа Content-Length указывает необходимую длину тела сообщения в байтах	Content-Length: 3495
Content-Location	Поле заголовка ответа Content-Location используется для идентификации исходного местоположения объекта на сервере.
Content-MD5	Поле заголовка ответа Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения.	Content-MD5:
Content-Range	Поле заголовка ответа Content-Range используется в том случае, когда клиент запрашивает фрагмент HTTP сообщение. Данное поле имеет значение байтового диапазона требуемого фрагмента	Content-Range: bytes 88080384-160993791/160993792
Content-Type	Поле заголовка ответа Content-Type используется для указания медиа типа данных в теле сообщения.	Content-Type: text/html;charset=utf-8
Content-Version	Поле заголовка ответа Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется)
Derived-From	Поле заголовка ответа Derived-From это аналог Content-Version (обычно не реализуется)
Expires	Поле заголовка ответа Expires содержит дату и время того момента, когда информация HTTP объекта перестанет быть актуальной	Expires: Tue, 31 Jan 2012 15:02:53 GMT
Last-Modified	Поле заголовка ответа Last-Modified содержит дату последней модификации HTTP объекта	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Link	Поле заголовка ответа Link указывает на логически связный с сущностью ресурс (обычно не реализуетсяя)
Title	Поле заголовка ответа Title содержит заголовок объекта

Общие поля HTTP заголовка

Напомню, что общие поля заголовка HTTP сообщения могут быть использованы, как при HTTP запросах, так и при ответах сервера. Ниже вы найдете таблицу с кратким описанием и примерами общих полей HTTP заголовка. Справочник общих полей HTTP заголовка отсортирован по алфавиту.

Поля HTTP заголовка	Описание поля HTTP заголовка	Пример
Cache-Control	Общее поле HTTP заголовка Cache-Control определяет директивы для управления кэшем, которым должны следовать все кэширующие механизмы	Cache-Control: no-cache Cache-Control: no-store Cache-Control: max-age=3600 Cache-Control: max-stale=0 Cache-Control: min-fresh=0 Cache-Control: no-transform Cache-Control: only-if-cached Cache-Control: cache-extension
Connection	Общее поле HTTP заголовка Connection позволяет управлять HTTP соединением	Connection: close
Date	Общее поле HTTP заголовка хранит дату и время создания HTTP сообщения	Date: Tue, 15 Nov 1994 08:12:31 GMT
MIME-Version	Общее поле HTTPзаголовка MIME-Version содержит версия протокола MIME, по которому было сформировано сообщение.	MIME-Version = «MIME-Version» «:» 1DIGIT «.» 1DIGIT
Pragma	Общее поле HTTP заголовка Pragma используется для включения особых директив, которые применяются к любому получателю HTTP сообщения.	Pragma: no-cache
Trailer	Общее поле HTTP заголовка Trailer хранит в себе список полей, которые имеют отношение к кодированию сообщения и кодированию передачи.	Trailer:field-name
Transfer-Encoding	Общее поле HTTP заголовка Transfer-Encoding служит для передачи списка методов кодирования передачи	Transfer-Encoding: chunked
Upgrade	Общее поле HTTP заголовкаUpgrade служит для передачи версий , которые поддерживает клиент. Сервер на сообщение со списком отвечает сообщением с одним протоколом	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via	Общее поле HTTP заголовкаVia служит для отображения списка , названий и версий прокси-серверов, через которые прошло сообщение.	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Поля заголовка объекта HTTP сообщения

Напомню, что поля заголовка объекта HTTP сообщения используются для того, чтобы могли договориться между собой о том, как они будут обмениваться полезной для пользователя информацией и в каком виде эта информация будет представлена. Ниже в таблице в найдете поля заголовка объекта HTTP сообщения. Справочник полей заголовка объекта HTTP сообщения упорядочен по алфавиту.

Поля HTTP заголовка	Описание поля HTTP заголовка	Пример	Тип HTTP сообщения
Allow	Поле заголовка Allow передает клиенту методы, которые тот может использовать	Allow: GET, HEAD, PUT	Ответ
Content-Disposition	Поле заголовка Content-Disposition используется для сохранения файлов на сервере		Запрос и ответ
Content-Encoding	Поле заголовка Content-Encoding указывает на дополнительный способ кодирования тела HTTP объекта с целью сжатия	Content-Encoding: gzip	Запрос и ответ
Content-Language	Поле заголовка Content-Language указывает клиенту на каком языке информация, находящаяся в теле объекта.	Content-Language: mi, en	Запрос и ответ
Content-Length	Поле заголовка Content-Length указывает необходимую длину тела сообщения в байтах	Content-Length: 3495	Запрос и ответ
Content-Location	Поле заголовка Content-Location используется для идентификации исходного местоположения объекта на сервере.	«Content-Location» «:»absoluteURI \| relativeURI)	Запрос и ответ
Content-MD5	Поле заголовка Content-MD5 используется для проверки целостности объектов сообщений, так как хэш значительно меньше самого сообщения.	Content-MD5:	Запрос и ответ
Content-Range	Поле заголовка Content-Range используется в том случае, когда запрашивает фрагмент HTTP сообщение. Данное поле имеет значение байтового диапазона требуемого фрагмента	Content-Range: bytes 88080384-160993791/160993792	Запрос и ответ
Content-Type	Поле заголовка Content-Type используется для указания медиа типа данных в теле сообщения.	Content-Type: text/html;charset=utf-8	Запрос и ответ
Content-Version	Поле заголовка Content-Version содержит информацию о текущей версии HTTP объекта (обычно не реализуется)		Запрос и ответ
Derived-From	Поле заголовка Derived-From это аналог Content-Version (обычно не реализуется)		Запрос и ответ
Expires	Поле заголовка Expires содержит дату и время того момента, когда информация HTTP объекта перестанет быть актуальной	Expires: Tue, 31 Jan 2012 15:02:53 GMT	Запрос и ответ
Last-Modified	Поле заголовка Last-Modified содержит дату последней модификации HTTP объекта	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT	Запрос и ответ
Link	Поле заголовка Link указывает на логически связный с сущностью ресурс (обычно не реализуется)		Запрос и ответ
Title	Поле заголовка Title содержит заголовок объекта		Запрос и ответ

Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением !

Коды состояния В данной статье содержатся общие сведения о заголовках HTTP .
Описание конкретных заголовков смотрите в статье Список заголовков HTTP .

Общий формат

Название : Значение

Название параметра должно состоять минимум из одного печатного символа (ASCII -коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.

Значение может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).

Предусматривается размещение значения на нескольких строках (перенос строки). Для указания переноса в начале следующей строки должен находиться хотя бы один пробельный символ.

Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовов должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.

Пример с многострочными значениями и одинаковыми именами заголовков (обратите внимание на регистр символов и пробелы):

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

Правильный компактный вариант преобразования и интерпретации:

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

В этом случае не допустимо принимать значение Content-Length равное 356. При объединении значений Allow чтобы не потерять семантический смысл была добавлена запятая в конец первого поля и убран бессмысленно дублирующийся элемент «GET».

Применяемые в заголовках структуры

Дата и время

Только дата указывается в заголовках Date , Expires , Last-Modified , If-Modified-Since , If-Unmodified-Since . Дата может присутствовать в заголовках If-Range и Warning .

В HTTP исторически используется три формата:

Fri, 04 Jul 2008 08:42:36 GMT - RFC 822 .
Friday, 04-Jul-08 08:42:36 GMT - RFC 850 .
Fri Jul 4 08:42:36 2008 - результат функции asctime() языка ANSI C .

Сейчас рекомендуется использовать только первый формат по RFC 822 , но для совместимости клиентам и серверам лучше поддерживать и другие.

Время всегда указывается для часового пояса GMT (UTC+0). Год записывается четырьмя цифрами. День, час, минута и секунда дополняются нулями до двух символов. Для месяца и названия недели применяются трёхбуквенные стандартные сокращения на английском языке.

Дни недели начиная с понедельника: Mon , Tue , Wed , Thu , Fri , Sat , Sun .

Месяцы с января по декабрь: Jan , Feb , Mar , Apr , May , Jun , Jul , Aug , Sep , Oct , Nov , Dec .

В PHP для преобразования местного времени во время по Гринвичу используется функция gmdate(). Примеры формирования дат для заголовков HTTP:

// Текущая дата формирования документа: header ("Date: " . gmdate ("D, d M Y H:i:s" , time () ) . " GMT" ) ; // Дата модификации из указанного файла: $fp = "data/my-foo.txt" ; // путь к файлу header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" , filemtime ($fp ) ) . " GMT" ) ; // Документ предположительно изменится через час: header ("Expires: " . gmdate ("D, d M Y H:i:s" , time () + 3600 ) . " GMT" ) ; // 3600 - количество секунд относительно текущего момента.

Байтовые диапазоны

При работе с фрагментами содержимого в специальных заголовках используются байтовые диапазоны (англ. byte ranges ). В них можно указать как один фрагмент, так и несколько разделяя их запятыми « , ». Диапазоны применяются в заголовках Range и Content-Range . В заголовке Accept-Ranges перечисляются только единицы измерения.

В байтовых диапазонах обязательно в начале указываются название единиц измерения за которым следует символ « = ». В настоящий момент кроме единиц bytes никакие другие не применяются. За символом « = » располагаются сами диапазоны. Каждый из них является разделённой дефисом « - » парой натуральных чисел или нуля. Первый элемент указывает начальный байт, а второй - конечный. Нумерация в диапазонах начинается с нуля.

Начальный или конечный байт может быть не указан. При отсутствии последнего байта считается что речь идёт о фрагменте от начального байта до конца содержимого. Если отсутствует начало, то номер конечного байта воспринимается как количество запрашиваемых байт от конца содержимого.

Если первый байт больше чем последний, то диапазон считается неправильным. Диапазоны с недопустимыми значениями игнорируются. Если первый байт выходит за пределы объёма ресурса, то диапазон игнорируется. Если последний байт выходит за пределы содержимого, то диапазон обрезается до конца.

Блок байтовых диапазонов считается выполнимым если в нём содержится хотя бы один доступный диапазон. Если же все диапазоны некорректны или выходят за пределы объёма ресурса, то серверу следует вернуть сообщение со статусом 416 (Requested range not satisfiable).

Примеры (весь объём ресурса - 5000 байт):

bytes=0-255 - фрагмент от 0-го до 255-го байта включительно.
bytes=42-42 - запрос одного 42-ого байта.
bytes=4000-7499,1000-2999 - два фрагмента. Так как первый выходит за пределы, то он интерпретируется как « 4000-4999 ».
bytes=3000-,6000-8055 - первый интерпретируется как « 3000-4999 », а второй игнорируется.
bytes=-400,-9000 - последние 400 байт (от 4600 до 4999), а второй подгоняется под рамки содержимого (от 0 до 4999) обозначая как фрагмент весь объём.
bytes=500-799,600-1023,800-849 - при пересечениях диапазоны могут объединяться в один (от 500 до 1023).

Работа с заголовками

Заголовки в HTML

Язык разметки HTML позволяет задавать необходимые значения заголовков HTTP внутри с помощью тэга . При этом название заголовка указывается в атрибуте http-equiv , а значение - в content . Почти всегда выставляется значение заголовка Content-Type с указанием кодировки чтобы избежать проблем с отображением текста браузером. Так же не лишним является указание значения заголовка Content-Language:

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

Поля заголовка HTTP предоставляют необходимую информацию о запросе или ответ, или об объекте отправленного в теле сообщения. Есть четыре типа заголовков HTTP сообщений:

General-header: Эти поля заголовка имеет общую применимость как для сообщений запроса и ответа.

Client Request-header: Эти поля заголовка имеет применимость только для запроса сообщений.

Server Response-header: Эти поля заголовка имеет применимость только для ответных сообщений.

Entity-header: Эти поля заголовка определяют метаинформацию о теле объекта или, если тело не присутствует, относительно ресурса, идентифицированного по запросу.

Общие Заголовки

Cache-Control

Общее поле заголовка Cache-Control используется для указания директивы, которые должны соблюдаться всеми системы кэширования. Синтаксис выглядит следующим образом:

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

Клиент HTTP или сервер может использовать Cache-control общего заголовок, чтобы задать параметры для кэша или запросить определенные виды документов из кэша. Директивы кэширования указаны в списке через запятую. Например:

Cache-control: no-cache

В следующей таблице перечислены важные директивы запроса кэша, которые могут быть использованы клиентом в запросе HTTP:

SN
1	no-cache Кэш не должен использовать ответ, чтобы удовлетворить последующий запрос без успешной переаттестации с сервером происхождения.
2	no-store
3	max-age = seconds
4	max-stale [ = seconds ] Указывает, что клиент желает принять ответ, который превысил его время истечения срока действия. Если секунды дано, оно не должно быть истек более чем на это время.
5	min-fresh = seconds Указывает, что клиент желает принять ответ, чья свежесть жизни не меньше, чем его текущий возраст плюс указанное время в секундах.
6	no-transform
7	only-if-cached Не получать новые данные. Кэш может отправить документ только если он находится в кэше, и не должен обращаться происхождения-сервера, чтобы увидеть, если новая копия существует.

Следующие важные директивы ответа кэша, которые могут быть использованы сервером в его HTTP-ответ:

SN	Cache Request Директива и описание
1	public Указывает, что ответ может быть в кэше любого кэша.
2	private Указывает, что все или часть ответного сообщения предназначена для одного пользователя и не должны кэшировать общий кэш.
3	no-cache Кэш не должен использовать ответ, чтобы удовлетворить последующий запрос без успешной повторной проверки с исходным сервером.
4	no-store Кэш не должен ничего о запросе клиента или ответ сервера хранения.
5	no-transform Не преобразовывать тело объекта.
6	must-revalidate Кэш должен проверить состояние несвежих документов, прежде чем использовать его, и те, с истекшим сроком годности не должны использоваться.
7	proxy-revalidate Директива прокси-REVALIDATE имеет тот же смысл, что и директива MUST- перепроверить, за исключением того, что он не относится к неразделяемым кэшам агента пользователя.
8	max-age = seconds Указывает, что клиент желает принять ответ, возраст которого не превышает заданного времени в секундах.
9	s-maxage = seconds Максимальный возраст, определяемый этой директива перекрывает максимальный возраст, указанный либо максимальный возраст директивы или заголовок Expires. Директива s-MaxAge всегда игнорируется частный кэш.

соединение

Общее поле заголовка Connection позволяет отправителю указать параметры, требуемые для данного конкретного соединения и не должны быть сообщены прокси-серверами через дополнительные соединения. Ниже приведен простой синтаксис для использования заголовка соединения:

Connection: "Connection"

HTTP / 1.1 определяет "close" вариант подключения для отправителя, чтобы сигнализировать о том, что соединение будет закрыто после завершения реакции. Например:

Connection: close

По умолчанию, HTTP 1.1 использует постоянные соединения, где соединение не закрывается автоматически после операции. HTTP 1.0, с другой стороны, не имеют постоянные соединения по умолчанию. Если клиент желает 1,0 использовать постоянные соединения, он использует keep-alive параметр следующим образом:

Connection: keep-alive

Дата

Все марка даты HTTP / время должна быть представлена в Greenwich Mean Time (GMT) , без исключения. HTTP приложение может использовать любого из следующих трех представлений отметок даты / времени:

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

Общее поле заголовка Pragma используется для включения реализации конкретных директив, которые могут применяться к любому получателю вдоль цепочки запроса / ответа. Например:

Pragma: no-cache

Только директива определена в HTTP / 1.0 это директива не-кэша и поддерживается в HTTP 1.1 для обратной совместимости. Нет новых директив Pragma не будут определены в будущем.

трейлер

Общее значение поля прицепа указует на то, что данный набор полого заголовка присутствует в прицепе сообщения, закодированное с фрагментированной передачей-кодированием. Ниже приведен синтаксис поля заголовка Trailer:

Trailer: field-name

поля заголовка сообщения, перечисленные в поле заголовка прицепа не должны включать в себя следующие поля заголовка:

Transfer-Encoding

Transfer-Encoding поле общего заголовка указывает на то, какой тип преобразования был применен к телу сообщения для того, чтобы безопасно передавать его между отправителем и получателем. Это не то же самое, как контент-кодирование, так как передача-кодироаки свойство сообщения, а не тело объекта. Синтаксис поля заголовка Transfer-Encoding выглядит следующим образом:

Transfer-Encoding: chunked

Все передачи кодирования значения не чувствительны к регистру.

Обновить

Upgrade общего заголовок позволяет клиенту определять, какие дополнительные протоколы связи он поддерживает и хотел бы использовать, если сервер считает необходимым для переключения протоколов. Например:

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

С помощью

Via общего заголовка должен использоваться шлюзами и прокси, чтобы указать промежуточные протоколы и получателей. Например, сообщение запроса может быть отправлено с HTTP / 1.0 агента пользователя к внутреннему прокси - серверу под кодовым названием "fred" , который использует HTTP / 1.1 для пересылки запроса на публичный прокси в nowhere.com, что завершает запрос, направить его на сервер происхождения в www.ics.uci.edu. Запрос, полученный www.ics.uci.edu бы тогда следующее поле заголовка Via:

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

Поле заголовка Обновление предназначено, чтобы обеспечить простой механизм для перехода от HTTP / 1.1 к некоторому другому, несовместимому протоколу.

Предупреждение

Warning общего заголовка используется для передачи дополнительной информации о состоянии или преобразовании сообщения, которые не могут быть отражены в сообщении. Ответ может содержать более одного заголовка Warning.

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

Запрос клиента Заголовки

принимать

Accept Поле заголовка запроса может быть использовано для указания определенных типов носителей, которые являются приемлемыми для ответа. Общий синтаксис выглядит следующим образом:

Accept: type/subtype

Несколько типов носителей могут быть перечислены через запятую и опциональный величина Q представляет собой приемлемый уровень качества для типов принимают по шкале от 0 до 1. Ниже приведен пример:

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

Это будет интерпретироваться как text/html и text/xc и являются предпочтительными типами носителей, но если они не существуют, а затем отправить text/x-dvi сущность, и если это не существует, отправьте text/plain объект.

Accept-Charset

Accept-Charset Поле заголовка запроса может быть использовано для указания, какие наборы символов являются приемлемыми для ответа. Ниже приводится общий синтаксис:

Accept-Charset: character_set

Множественные наборы символов могут быть перечислены через запятую и опциональный величина Q представляет собой приемлемый уровень качества для непредпочтительных наборов символов по шкале от 0 до 1. Ниже приведен пример:

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

Специальное значение "*" , если он присутствует в Accept-Charset поля, соответствует каждому набору символов, и если нет Accept-Charset заголовка отсутствует, по умолчанию является то, что любой набор символов является приемлемым.

Accept-Encoding

Accept-Encoding Поле заголовка запроса похоже на Accept, но ограничивает контент-кодировку, которые являются приемлемыми в ответ. Общий синтаксис:

Accept-Encoding: encoding types

Примерами являются следующие:

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

Accept-Language Поле заголовка запроса похоже на Accept, но ограничивает набор естественных языков, которые являются предпочтительными в качестве ответа на запрос. Общий синтаксис:

Accept-Language: language

Несколько языков могут быть перечислены через запятую и опциональный величина Q представляет собой приемлемый уровень качества для не предпочтительных языков по шкале от 0 до 1. Ниже приведен пример:

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

авторизация

Authorization значение поля заголовка запроса состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрошенного ресурса. Общий синтаксис:

Authorization: credentials

HTTP / 1.0 спецификация определяет схему авторизации BASIC, где параметр авторизации является строка username:password закодирован в базе 64. Ниже приведен пример:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Значение декодирует в это guest:guest123 , где guest является ID пользователя и guest123 это пароль.

печенье

Cookie значение поля заголовка запроса содержит имя / значение пары информации, хранимой для этого URL. Ниже приводится общий синтаксис:

Cookie: name=value

Несколько печенье могут быть отделены друг от запятой следующим образом:

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

ожидать

Expect поле заголовка запроса используется для указания того, что конкретный набор серверов поведения требуется клиентом. Общий синтаксис:

Expect: 100-continue | expectation-extension

Если сервер получает запрос, содержащий поле ожидать, что включает в себя ожидание-расширение, что он не поддерживает, она должна отвечать с 417 (Expectation Failed) соответствует (Expectation Failed) статус.

Из

From заголовка запроса поле содержит интернет - адрес электронной почты для человеческого пользователя, который управляет запрашивающего агента пользователя. Ниже приведен простой пример:

From: [email protected]

Это поле заголовка может быть использовано для целей каротажа и в качестве средства для идентификации источника недействительных или нежелательных запросов.

хозяин

Host поле заголовка запроса используются для указания хоста Интернета и номер порта запрошенного ресурса. Общий синтаксис:

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

host без задней порта информации подразумевает порт по умолчанию, которое 80. Например, запрос на сервере происхождения для http://www.w3.org/pub/WWW/ будет:

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

If-Match

If-Match Поле заголовка запроса используется с методом, чтобы сделать его условным. Этот заголовок запрашивает сервер выполнить запрошенный метод, только если данное значение в этой метке соответствует данному объекту тегов, представленных ETag . Общий синтаксис:

If-Match: entity-tag

Звездочка (*) соответствует любому объекту, и транзакция продолжается, только если объект существует. Ниже приведены возможные примеры:

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

If-Modified-Since

If-Modified-Since как поле заголовка запроса используется с методом, чтобы сделать его условным. Если запрашиваемый URL не был изменен со времени, указанного в этом поле, объект не будет возвращен с сервера; вместо этого, 304 (not modified) ответа будет возвращен без тела сообщения. Общий синтаксис If-Modified-так есть:

If-Modified-Since: HTTP-date

Пример поля:

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

Если ни один из сущности не помечает матч, или если "*" дается и не текущий объект не существует, сервер не должен выполнить запрошенный метод, и должен вернуть 412 (Precondition Failed) ответ.

If-None-Match

If-None-Match Поле заголовка запроса используется с методом, чтобы сделать его условным. Этот заголовок запрашивает сервер выполнить запрошенный метод, только если один из заданного значения в этой метке соответствуют данному объекту теги, представленных ETag . Общий синтаксис:

If-None-Match: entity-tag

Звездочка (*) соответствует любому объекту, и транзакция продолжается, только если объект не существует. Ниже приведены возможные примеры:

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

If-Range

If-Range поле заголовка запроса может быть использовано с условным GET запросить только ту часть лица, которая отсутствует, если она не была изменена, и весь объект, если он был изменен. Общий синтаксис выглядит следующим образом:

If-Range: entity-tag | HTTP-date

Либо метка объекта или дата может быть использована для идентификации парциального лица уже получили. Например:

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

При этом, если документ не был изменен с момента указанной даты, сервер возвращает диапазон байтов заданный заголовком Range, в противном случае она возвращает все новый документ.

Если-Unmodified-С

If-Unmodified-Since как поле заголовка запроса используется с методом, чтобы сделать его условным. Общий синтаксис:

If-Unmodified-Since: HTTP-date

Если запрошенный ресурс не был изменен с момента времени, указанным в этом поле, сервер должен выполнить требуемую операцию, как если бы If-немодифицированный-Так как заголовок не присутствовал. Например:

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

Если запрос приводит к чему, кроме 2xx или 412 статуса, If-Unmodified-Since заголовка следует игнорировать.

Max-Нападающие

Max-Forwards поле заголовка запроса предоставляет механизм с методами TRACE и OPTIONS , чтобы ограничить число прокси или шлюзов, которые могут переадресовывать запрос следующего входящего сервера. Вот общий синтаксис:

Max-Forwards: n

Значение Max-Нападающие представляет собой десятичное число, указывающее оставшееся количество раз это сообщение запроса может быть передана. Это полезно для отладки с помощью метода TRACE, избегая бесконечные циклы. Например:

Max-Forwards: 5

Поле заголовка Max-Нападающие может быть проигнорировано для всех других методов, определенных в спецификации HTTP.

Proxy-Authorization

Proxy-Authorization Поле заголовка запроса позволяет клиенту идентифицировать себя (or its user) к прокси - сервер, который требует проверки подлинности. Вот общий синтаксис:

Proxy-Authorization: credentials

Ассортимент

Range Поле заголовка запроса определяет частичный range(s) содержаний запрашиваемых из документа. Общий синтаксис:

Range: bytes-unit=first-byte-pos "-"

Значение первого байта-полюсное в байтах-диапазон-спецификации дает байтовое смещение первого байта в диапазоне. Значение последнего байта-полюсная дает байтовое смещение последнего байта в диапазоне; то есть, позиции байтов указанные включают. Вы можете указать байтовый блок в байтах. Байт смещения начинается с нуля. Некоторые простые примеры являются следующими:

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

Несколько диапазонов могут быть перечислены через запятую. Если первая цифра в разделенных запятыми байт range(s) отсутствует, диапазон предполагается считать от конца документа. Если вторая цифра отсутствует, диапазон байт п до конца документа.

Referer

Referer Поле заголовка запроса позволяет клиенту указать адрес (URI) ресурса, из которого была запрошена URL. Общий синтаксис выглядит следующим образом:

Referer: absoluteURI | relativeURI

Ниже приведен простой пример:

Referer: http://www.tutorialspoint.org/http/index.htm

Если значение поля является относительным URI, он должен интерпретироваться относительно Request-URI .

TE

TE Поле заголовка запроса указывает на то, что расширение transfer-coding она готова принять в ответ и будет ли он готов принять поля трейлера в фрагментированное transfer-coding . Ниже приводится общий синтаксис:

TE: t-codings

Наличие ключевого слова "trailers" указует на то, что клиент готов принять поля прицепа в виде фрагментированного кодирования передачи и задаются либо из способов:

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

Если поле значения ТЕ пусто или, если ни одно из полей ТЕ не присутствует, то только передать-кодирование chunked . Сообщение, без передачи кодирования всегда является приемлемым.

User-Agent

User-Agent Поле заголовка запроса содержит информацию об агенте пользователя, отправляющего запрос. Ниже приводится общий синтаксис:

User-Agent: product | comment

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

Серверные заголовки ответа

Accept-Ranges

Accept-Ranges поле заголовка отклика позволяет серверу указывать свое принятие запросов диапазона для ресурса. Общий синтаксис:

Accept-Ranges: range-unit | none

Например, сервер, который принимает запросы на байт-диапазон может отправить:

Accept-Ranges: bytes

Серверы, которые не принимают каких-либо запроса диапазона на ресурс может отправить:

Accept-Ranges: none

Это будет консультировать клиента не пытаться запроса диапазона.

Возраст

Age Поле заголовка отклика передает оценку отправителя суммы времени с момента ответа (or its revalidation) был создан на сервере происхождения. Общий синтаксис:

Age: delta-seconds

значения Возраст неотрицательные десятичные целые числа, представляющие собой время в секундах. Ниже приведен простой пример:

Age: 1030

/ Сервер HTTP 1.1, который включает в себя кэш должен включать в себя поле заголовка Возраста в каждом ответ генерируется из своего кэша.

ETag

ETag Поле заголовка отклика обеспечивает текущее значение тега объекта для запрошенного варианта. Общий синтаксис:

ETag: entity-tag

Вот несколько простых примеров:

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

Место нахождения

Location поле заголовка отклика используется для перенаправления получателя в другом месте, чем Request-URI для завершения. Общий синтаксис:

Location: absoluteURI

Ниже приведен простой пример:

Location: http://www.tutorialspoint.org/http/index.htm

Поле заголовка Content-Location отличается от места в том, что Content-Location идентифицирует исходное местоположение объекта, заключенный в запросе.

Proxy-Authenticate

Proxy-Authenticate поле заголовка отклика должен быть включен в качестве части 407 (Proxy Authentication Required) ответ. Общий синтаксис:

Proxy-Authenticate: challenge

Retry-After

Retry-After поле заголовка ответа могут быть использованы с 503 (Service Unavailable) ответ, чтобы указать, как долго обслуживание, как ожидается, будут недоступны для запрашивающего клиента. Общий синтаксис:

Retry-After: HTTP-date | delta-seconds

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

В последнем примере, задержка 2 минуты.

сервер

Server поле заголовка отклика содержит информацию о программном обеспечении, используемом сервером происхождения, чтобы обработать запрос. Общий синтаксис:

Server: product | comment

Ниже приведен простой пример:

Server: Apache/2.2.14 (Win32)

Если ответ пересылаются через прокси-сервер, приложение прокси не должно изменить заголовок ответа сервера.

Set-Cookie

Set-Cookie поле заголовка отклика содержит имя / значение пары информации, чтобы сохранить для этого URL. Общий синтаксис:

Set-Cookie: NAME=VALUE; OPTIONS

заголовок ответа Set-Cookie содержит маркер Set-Cookie, а затем через запятую список из одного или более печенья. Вот возможные значения, которые можно указать в качестве опции:

Ниже приведен пример простого печенья заголовка генерируется сервером:

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

изменяться

Vary Поле заголовка отклика указывает, что объект имеет несколько источников и, следовательно, может изменяться в соответствии с указанным списком запроса header(s) . Ниже приводится общий синтаксис:

Vary: field-name

Можно указать несколько заголовков, разделенных запятыми и значением звездочки "*" сигналы, которые неуказанные параметры не ограничиваются запросом заголовков. Ниже приведен простой пример:

Vary: Accept-Language, Accept-Encoding

Здесь имена полей не чувствительны к регистру.

WWW-Authenticate

WWW-Authenticate Поле заголовка отклика должно быть включено в 401 (Unauthorized) ответных сообщений. Значение поля состоит из по меньшей мере одного вызова, который указывает на аутентификации scheme(s) и параметры, применимые к Request-URI. Общий синтаксис:

WWW-Authenticate: challenge

WWW-Аутентифицировать Значение поля может содержать более чем одну проблему, или если поле заголовка более одного WWW-Аутентифицировать обеспечивается, содержимое самой задачи может содержать список разделенных запятой параметров аутентификации. Ниже приведен простой пример:

WWW-Authenticate: BASIC realm="Admin"

Entity Заголовки

Позволять

Allow поле заголовка объекта перечисляет набор методов, поддерживаемых ресурса, идентифицированного Request-URI. Общий синтаксис:

Allow: Method

Можно указать несколько методов, разделенных запятыми. Ниже приведен простой пример:

Allow: GET, HEAD, PUT

Это поле не может помешать клиенту пробовать другие методы.

Content-Encoding

Content-Encoding Поле заголовка объекта используется в качестве модификатора к медиа-типа. Общий синтаксис:

Content-Encoding: content-coding

Content-Encoding: gzip

Content-Language

Content-Language Поле заголовка объекта описывает естественный language(s) о целевой аудитории для включенного объекта. Ниже приводится общий синтаксис:

Content-Language: language-tag

Несколько языков могут быть перечислены для контента, который предназначен для разных аудиторий. Ниже приведен простой пример:

Content-Language: mi, en

Основная цель Content-Language, чтобы позволить пользователю идентифицировать и дифференцировать объекты в соответствии с собственным предпочтительным языком пользователя.

Content-Length

Content-Length Поле заголовка объекта указывает размер тела объекта, в десятичное число октетов, посланный получателю или, в случае метода HEAD, размер тела объекта, который был бы послан, что запрос был GET. Общий синтаксис:

Content-Length: DIGITS

Ниже приведен простой пример:

Content-Length: 3495

Любой Content-Length больше или равно нулю, является допустимым значением.

Content-Location

Content-Location Поле заголовка объекта может быть использовано для питания местоположения ресурса для объекта, заключенного в сообщении, когда этот объект доступен из расположения отдельно от URI запрашиваемого ресурса. Общий синтаксис:

Content-Location: absoluteURI | relativeURI

Ниже приведен простой пример:

Content-Location: http://www.tutorialspoint.org/http/index.htm

Значение Content-Location также определяет базу URI для объекта.

Content-MD5

Content-MD5 Поле заголовка объекта может быть использован для подачи на контрольную сумму MD5 субъекта для проверки целостности сообщения при получении. Общий синтаксис:

Content-MD5: md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Ниже приведен простой пример:

Content-MD5:

MD5 дайджест вычисляется на основе содержимого тела объекта, включая любой контент-кодирование, который был применен, но не включая любую передачу кодирование, приложенное к телу сообщения.

Content-Range

Content-Range поле заголовка объекта передаются с частичным телом объекта, чтобы определить, где в полном теле объекта должно быть применено частичное тело. Общий синтаксис:

Content-Range: bytes-unit SP first-byte-pos "-" last-byte-pos

Примеры значений байт-контент диапазон спецификации, если предположить, что объект содержит в общей сложности 1234 байт:

The first 500 bytes: Content-Range: bytes 0-499/1234 - The second 500 bytes: Content-Range: bytes 500-999/1234 - All except for the first 500 bytes: Content-Range: bytes 500-1233/1234 - The last 500 bytes: Content-Range: bytes 734-1233/1234

Когда сообщение HTTP включает в себя содержание одного диапазона, это содержание передается с заголовком Content-Range и Content-Length заголовок, показывающий количество байтов, фактически переданы. Например,

HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif

Тип содержимого

Content-Type поле заголовка объекта указывает тип носителя тела объекта, отправляемого получателю или, в случае метода HEAD, тип носителя, который был бы послан, если бы запрос был GET. Общий синтаксис:

Content-Type: media-type

Ниже приведен пример:

Content-Type: text/html; charset=ISO-8859-4

Истекает

Expires Поле заголовка объекта дает дату / время, после чего ответ считается устаревшим. Общий синтаксис:

Expires: HTTP-date

Ниже приведен пример:

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

Последнее изменение

Last-Modified Поле заголовка объекта указывает дату и время, при котором исходный сервер считает вариант последнего изменения. Общий синтаксис:

Last-Modified: HTTP-date

Ниже приведен пример:

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

Список кодов состояния HTTP

Код состояния HTTP (англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: (введён Microsoft) и (введён в cPanel).

Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.

Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается - он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе "Коды состояния служб IIS" в Базе знаний Microsoft.

1xx: Informational (Информационные)

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue (Продолжать) - Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101 Switching Protocols (Переключение протоколов) - Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing (Идёт обработка) - Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) - При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

2xx: Success (Успешно)

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

200 OK (Хорошо) - Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201 Created (Создано) - В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом . Появился в HTTP/1.0.

202 Accepted (Принято) - Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203 Non-Authoritative Information (Информация не авторитетна) - Аналогично ответу , но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204 No Content (Нет содержимого) - Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205 Reset Content (Сбросить содержимое) - Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206 Partial Content (Частичное содержимое) - Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.

207 Multi-Status (Многостатусный) - Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226 IM Used (Использовано IM) - Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Redirection (Перенаправление)

Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов , и относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

По последним стандартам клиент может производить перенаправление автоматически (без запроса пользователя) только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях если метод был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом чтобы в случае чего пользователь смог сам произвести переход.

Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами и ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды и вместо . Изменять метод нужно только если сервер ответил . В остальных случаях следующий запрос производить с исходным методом.

300 Multiple Choices (Несколько вариантов выбора) - По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301 Moved Permanently (Перемещено навсегда) - Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302 Moved Temporarily / Found (Перемещено временно / Найдено) - Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303 See Other (Смотреть другое) - Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом , указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304 Not Modified (Не изменялось) - Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305 Use Proxy (Использовать прокси) - Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306 (Зарезервировано, код использовался только в ранних спецификациях) - Использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307 Temporary Redirect (Временное перенаправление) - Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx: Client Error (Ошибка клиента)

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request (Плохой запрос) - Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401 Unauthorized (Неавторизован) - Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402 Payment Required (Необходима оплата) - Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 Forbidden (Запрещено) - Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ или при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам.htaccess или.htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404 Not Found (Не найдено) - Самая распространенная ошибка при пользовании Интернетом, основная причина - ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код . Ответ может использоваться вместо , если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405 Method Not Allowed (Метод не поддерживается) - Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код (Not Implemented). Появился в HTTP/1.1.

406 Not Acceptable (Неприемлемо) - Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407 Proxy Authentication Required (Необходима прокси авторизация) - Ответ аналогичен коду за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408 Request Timeout (Истекло время ожидания) - Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409 Conflict (Конфликт) - Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410 Gone (Удалён) - Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код . Появился в HTTP/1.1.

411 Length Required (Необходима длина) - Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412 Precondition Failed (Условие ложно) - Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.

413 Request Entity Too Large (Размер запроса слишком велик) - Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414 Request-URI Too Large (Запрашиваемый URI слишком длинный) - Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415 Unsupported Media Type (Неподдерживаемый тип данных) - По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) - в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).

417 Expectation Failed (Ожидаемое неприемлемо) - По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

418 I"m a teapot (Я - чайник) - Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.

422 Unprocessable Entity (Необрабатываемый экземпляр) - Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423 Locked (Заблокировано) - Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424 Failed Dependency (Невыполненная зависимость) - Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425 Unordered Collection (Неупорядоченный набор) - используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.

426 Upgrade Required (Необходимо обновление) - Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

428 Precondition Required (Необходимо предусловие) - Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.

429 Too Many Requests (Слишком много запросов) - Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.

431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) - Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.

434 Requested host unavailable. (Запрашиваемый адрес недоступен) - Запрашиваемый адрес недоступен.

449 Retry With (Повторить с) - Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) - Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери "451 градус по Фаренгейту".

456 Unrecoverable Error (Некорректируемая ошибка) - Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 () - Используется Nginx, когда клиент закрывает соединение до получения ответа.

5xx: Server Error (Ошибка сервера)

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500 Internal Server Error (Внутренняя ошибка сервера) - Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501 Not Implemented (Не реализовано) - Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ . Появился в HTTP/1.0.

502 Bad Gateway (Плохой, ошибочный шлюз) - Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503 Service Unavailable (Сервис недоступен) - Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504 Gateway Timeout (Шлюз не отвечает) - Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505 HTTP Version Not Supported (Версия HTTP не поддерживается) - Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506 Variant Also Negotiates (Вариант тоже проводит согласование) - В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage (Переполнение хранилища) - Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

508 Loop Detected (Обнаружена петля) -

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) - Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем "bw/limited", входящим в панель управления хостингом cPanel, где и был введён.

510 Not Extended (Нет расширения) - На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

511 Network Authentication Required (Требуется сетевая аутентификация) - Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником - например, сервером провайдера - в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

Cookie · ETag · Location · Referer DNT · X-Forwarded-For Коды состояния 301 Moved permanently 302 Found 303 See Other 403 Forbidden 404 Not Found В данной статье содержатся общие сведения о заголовках HTTP .
Описание конкретных заголовков смотрите в статье Список заголовков HTTP .

Заголовки HTTP (англ. HTTP Headers ) - это строки в HTTP-сообщении, содержащие разделённую двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

Все заголовки разделяются на четыре основных группы:

General Headers (рус. Основные заголовки ) - должны включаться в любое сообщение клиента и сервера.
Request Headers (рус. Заголовки запроса ) - используются только в запросах клиента.
Response Headers (рус. Заголовки ответа ) - только для ответов от сервера.
Entity Headers (рус. Заголовки сущности ) - сопровождают каждую сущность сообщения.

Общий формат

Название : Значение

Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовков должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.

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

Правильный компактный вариант преобразования и интерпретации:

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

Применяемые в заголовках структуры

Дата и время

В HTTP исторически используется три формата:

Fri, 04 Jul 2008 08:42:36 GMT - RFC 822 .
Friday, 04-Jul-08 08:42:36 GMT - RFC 850 .
Fri Jul 4 08:42:36 2008 - результат функции asctime() языка ANSI C .

Дни недели начиная с понедельника: Mon , Tue , Wed , Thu , Fri , Sat , Sun .

Месяцы с января по декабрь: Jan , Feb , Mar , Apr , May , Jun , Jul , Aug , Sep , Oct , Nov , Dec .

// Текущая дата формирования документа: header ("Date: " . gmdate ("D, d M Y H:i:s" , time () ) . " GMT" ) ; // Дата модификации указанного файла: $fp = "data/my-foo.txt" ; // путь к файлу header ("Last-Modified: " . gmdate ("D, d M Y H:i:s" , filemtime ($fp ) ) . " GMT" ) ; // Документ предположительно изменится через час: header ("Expires: " . gmdate ("D, d M Y H:i:s" , time () + 3600 ) . " GMT" ) ; // 3600 - количество секунд относительно текущего момента.

Байтовые диапазоны

Если первый байт больше чем последний, то диапазон считается синтаксически недействительным (англ. syntactically invalid ). Поля заголовка, содержащие диапазоны с синтаксически недействительными значениями, игнорируются. Если первый байт выходит за пределы объёма ресурса, то диапазон игнорируется. Если последний байт выходит за пределы содержимого, то диапазон обрезается до конца.

Печать

Также интересно:

Как выбрать центральный процессор, и зачем это нужно?

Восстановления раздела recovery ASUS

Где взять биткоин бесплатно?

Рекомендуем почитать:

2024-04-11 00:07:07

Как защитить свой форум на Simple Machines (SMF) от спама

2024-04-11 00:07:07

Установка виндовс с флешки через биос

2024-04-09 00:06:08

Тестирование web сервисов

В продолжение темы:

Android

Расширение VK Helper – ваш незаменимый помощник

Популярная социальная сеть ВКонтакте позволяет находить новых друзей и держать контакт со всеми близкими. Помимо этого, каждый пользователь может делиться собственными...

Новые статьи