HTTP - Краткое руководство

Протокол передачи гипертекста (HTTP) - это протокол прикладного уровня для распределенных, совместных гипермедийных информационных систем. Это основа для передачи данных во всемирной паутине (то есть в Интернете) с 1990 года. HTTP - это общий протокол без сохранения состояния, который можно использовать для других целей, а также с расширением его методов запроса, кодов ошибок и заголовков.

По сути, HTTP - это протокол связи на основе TCP / IP, который используется для доставки данных (файлов HTML, файлов изображений, результатов запросов и т. Д.) Во всемирную паутину. Порт по умолчанию - TCP 80, но можно использовать и другие порты. Он обеспечивает стандартизированный способ взаимодействия компьютеров друг с другом. Спецификация HTTP определяет, как данные запросов клиентов будут формироваться и отправляться серверу, и как серверы отвечают на эти запросы.

Основные характеристики

Существуют следующие три основные функции, которые делают HTTP простым, но мощным протоколом:

HTTP is connectionless:HTTP-клиент, т.е. браузер инициирует HTTP-запрос, и после того, как запрос сделан, клиент отключается от сервера и ждет ответа. Сервер обрабатывает запрос и повторно устанавливает соединение с клиентом, чтобы отправить ответ.
HTTP is media independent:Это означает, что любой тип данных может быть отправлен по HTTP, если и клиент, и сервер знают, как обрабатывать содержимое данных. Это необходимо для клиента и сервера, чтобы указать тип контента с использованием соответствующего MIME-типа.
HTTP is stateless:Как упоминалось выше, HTTP не поддерживает соединение, и это прямой результат того, что HTTP является протоколом без сохранения состояния. Сервер и клиент знают друг друга только во время текущего запроса. После этого они оба забывают друг о друге. Из-за такого характера протокола ни клиент, ни браузер не могут сохранять информацию между различными запросами на веб-страницах.

HTTP / 1.0 использует новое соединение для каждого обмена запрос / ответ, тогда как соединение HTTP / 1.1 может использоваться для одного или нескольких обменов запрос / ответ.

Базовая архитектура

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

Протокол HTTP - это протокол запроса / ответа, основанный на архитектуре клиент / сервер, где веб-браузер, роботы, поисковые системы и т. Д. Действуют как HTTP-клиенты, а веб-сервер действует как сервер.

Клиент

HTTP-клиент отправляет запрос на сервер в форме метода запроса, URI и версии протокола, за которым следует MIME-подобное сообщение, содержащее модификаторы запроса, информацию о клиенте и возможное содержимое тела через соединение TCP / IP.

Сервер

HTTP-сервер отвечает строкой состояния, включая версию протокола сообщения и код успеха или ошибки, за которым следует MIME-подобное сообщение, содержащее информацию о сервере, метаинформацию объекта и возможное содержимое тела объекта.

В этой главе будет перечислено несколько важных параметров протокола HTTP и их синтаксис в том виде, в каком они используются при обмене данными. Например, формат даты, формат URL-адреса и т. Д. Это поможет вам в построении ваших сообщений запроса и ответа при написании клиентских или серверных программ HTTP. Вы увидите полное использование этих параметров в следующих главах, объясняя структуру сообщений для HTTP-запросов и ответов.

Версия HTTP

HTTP использует <major>.<minor>схема нумерации для обозначения версий протокола. Версия сообщения HTTP указывается в поле HTTP-Version в первой строке. Вот общий синтаксис указания номера версии HTTP:

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

пример

HTTP/1.0

or

HTTP/1.1

Универсальные идентификаторы ресурсов (URI)

Унифицированные идентификаторы ресурсов (URI) - это просто отформатированная строка без учета регистра, содержащая имя, местоположение и т. Д. Для идентификации ресурса, например веб-сайта, веб-службы и т. Д. Общий синтаксис URI, используемый для HTTP, выглядит следующим образом:

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Здесь, если port пусто или не задано, порт 80 предполагается для HTTP и пустой abs_path эквивалентен abs_pathиз "/". Персонажи, не входящие вreserved и unsafe наборы эквивалентны их кодировке ""% "HEX HEX".

пример

Следующие два URI эквивалентны:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

Форматы даты / времени

Все метки даты и времени HTTP ДОЛЖНЫ быть представлены в среднем времени по Гринвичу (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

Наборы символов

Вы используете набор символов, чтобы указать наборы символов, которые предпочитает клиент. Можно указать несколько наборов символов через запятую. Если значение не указано, по умолчанию используется US-ASCII.

пример

Ниже приведены допустимые наборы символов:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

Кодировки контента

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

Все значения кодирования содержимого нечувствительны к регистру. HTTP / 1.1 использует значения кодирования содержимого в полях заголовка Accept-Encoding и Content-Encoding, которые мы увидим в следующих главах.

пример

Ниже приведены действующие схемы кодирования:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

Типы СМИ

HTTP использует типы Интернет-мультимедиа в Content-Type и Acceptполя заголовка, чтобы обеспечить открытую и расширяемую типизацию данных и согласование типов. Все значения типа носителя регистрируются в Internet Assigned Number Authority ((IANA). Ниже приводится общий синтаксис для указания типа носителя:

media-type     = type "/" subtype *( ";" parameter )

В именах атрибутов типа, подтипа и параметра регистр не учитывается.

пример

Accept: image/gif

Языковые теги

HTTP использует языковые теги внутри Accept-Language и Content-Languageполя. Тег языка состоит из одной или нескольких частей: тега основного языка и, возможно, пустой серии вложенных тегов:

language-tag  = primary-tag *( "-" subtag )

Пробелы внутри тега не допускаются, и все теги нечувствительны к регистру.

пример

Примеры тегов включают:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Если любой двухбуквенный первичный тег - это аббревиатура языка ISO-639, а любой двухбуквенный начальный вложенный тег - это код страны ISO-3166.

HTTP основан на модели архитектуры клиент-сервер и протоколе запросов / ответов без сохранения состояния, который работает путем обмена сообщениями через надежное соединение TCP / IP.

HTTP-клиент - это программа (веб-браузер или любой другой клиент), которая устанавливает соединение с сервером с целью отправки одного или нескольких сообщений HTTP-запроса. HTTP-сервер - это программа (обычно это веб-сервер, например, веб-сервер Apache или IIS Internet Information Services и т. Д.), Которая принимает соединения для обслуживания HTTP-запросов путем отправки сообщений HTTP-ответа.

HTTP использует унифицированный идентификатор ресурса (URI) для идентификации данного ресурса и установления соединения. Как только соединение установлено,HTTP messagesпередаются в формате, аналогичном формату, используемому почтой Интернета [RFC5322] и многоцелевыми расширениями электронной почты Интернета (MIME) [RFC2045]. Эти сообщения состоят изrequests от клиента к серверу и responses от сервера к клиенту, который будет иметь следующий формат:

HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

HTTP-запрос и HTTP-ответ используют общий формат сообщения RFC 822 для передачи необходимых данных. Этот общий формат сообщения состоит из следующих четырех элементов.


     
      A Start-line
 Zero or more header fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

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

Строка сообщения

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

start-line = Request-Line | Status-Line

Мы обсудим строку запроса и строку состояния при обсуждении сообщений HTTP-запроса и HTTP-ответа соответственно. А пока посмотрим на примеры начальной строки в случае запроса и ответа:

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

Поля заголовка

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

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

Все вышеупомянутые заголовки имеют один и тот же общий формат, и каждое поле заголовка состоит из имени, за которым следует двоеточие (:) и значение поля следующим образом:

message-header = field-name ":" [ field-value ]

Ниже приведены примеры различных полей заголовка:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Тело сообщения

Часть тела сообщения является необязательной для HTTP-сообщения, но если она доступна, она используется для переноса тела объекта, связанного с запросом или ответом. Если тело объекта связано, то обычноContent-Type и Content-Length строки заголовков определяют природу связанного тела.

Тело сообщения - это то, которое содержит фактические данные HTTP-запроса (включая данные формы, загруженные и т. Д.) И данные HTTP-ответа от сервера (включая файлы, изображения и т. Д.). Ниже приводится простое содержание тела сообщения:

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HTTP-клиент отправляет HTTP-запрос на сервер в форме сообщения запроса, которое включает в себя следующий формат:


     
      A Request-line
 Zero or more header (General|Request|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

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

Строка запроса сообщения

Строка запроса начинается с токена метода, за которым следует Request-URI и версия протокола, и заканчивается CRLF. Элементы разделяются пробелами SP.

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Давайте обсудим каждую часть, упомянутую в Request-Line.

Метод запроса

Запрос Method указывает метод, который будет выполняться на ресурсе, идентифицированном данным Request-URI. Метод чувствителен к регистру, и всегда следует указывать прописные буквы. Ниже приведены поддерживаемые методы в HTTP / 1.1.

SN	Метод и описание
1	GET Метод GET используется для получения информации с заданного сервера с использованием заданного URI. Запросы, использующие GET, должны только извлекать данные и не должны иметь никакого другого влияния на данные.
2	HEAD То же, что GET, но передает только строку состояния и раздел заголовка.
3	POST Запрос POST используется для отправки данных на сервер, например информации о клиенте, загрузки файлов и т. Д., С использованием HTML-форм.
4	PUT Замените все текущие представления целевого ресурса загруженным контентом.
5	DELETE Удалите все текущие представления целевого ресурса, заданные URI.
6	CONNECT Установите туннель к серверу, идентифицированному заданным URI.
7	OPTIONS Опишите варианты коммуникации для целевого ресурса.
8	TRACE Выполните тест обратной связи для сообщений на пути к целевому ресурсу.

Request-URI

Request-URI - это универсальный идентификатор ресурса, который определяет ресурс, к которому следует применить запрос. Ниже приведены наиболее часто используемые формы для указания URI:

Request-URI = "*" | absoluteURI | abs_path | authority

SN	Метод и описание
1	Звездочка используется, когда HTTP-запрос применяется не к конкретному ресурсу, а к самому серверу, и разрешен только в том случае, если используемый метод не обязательно применим к ресурсу. Например: OPTIONS HTTP/1.1**
2	В absoluteURIиспользуется при отправке HTTP-запроса к прокси. Прокси-сервер запрашивается для пересылки запроса или обслуживания его из допустимого кеша и возврата ответа. Например: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	Наиболее распространенная форма Request-URI - это та, которая используется для идентификации ресурса на исходном сервере или шлюзе. Например, клиент, желающий получить указанный выше ресурс непосредственно с исходного сервера, создаст TCP-соединение с портом 80 хоста «www.w3.org» и отправит строки: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Обратите внимание, что абсолютный путь не может быть пустым; если в исходном URI ничего нет, он ДОЛЖЕН быть указан как "/" (корень сервера)

Поля заголовка запроса

Мы изучим General-header и Entity-header в отдельной главе, когда будем изучать поля заголовка HTTP. А пока давайте проверим, что такое поля заголовка запроса.

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

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent

Вы можете ввести свои настраиваемые поля, если собираетесь написать свой собственный клиент и веб-сервер.

Примеры сообщений запроса

Теперь давайте соберем все это вместе, чтобы сформировать HTTP-запрос на получение hello.htm страница с веб-сервера, запущенного на сайте tutorialspoint.com

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

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

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Здесь указанный URL /cgi-bin/process.cgi будет использоваться для обработки переданных данных, и, соответственно, ответ будет перенастроен. Вотcontent-type сообщает серверу, что переданные данные являются простыми данными веб-формы и lengthбудет фактической длиной данных, помещенных в тело сообщения. В следующем примере показано, как передать XML плана на свой веб-сервер:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

После получения и интерпретации сообщения запроса сервер отвечает сообщением ответа HTTP:


     
      A Status-line
 Zero or more header (General|Response|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

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

Строка состояния сообщения

Строка состояния, состоящая из версии протокола, за которым следует числовой код состояния и связанная с ним текстовая фраза. Элементы разделяются пробелами SP.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Давайте обсудим каждую часть, упомянутую в статусной строке.

Версия HTTP

Сервер, поддерживающий HTTP версии 1.1, вернет следующую информацию о версии:

HTTP-Version = HTTP/1.1

Код состояния

Элемент Status-Code представляет собой трехзначное целое число, где первая цифра Status-Code определяет класс ответа, а последние две цифры не имеют роли категоризации. Первая цифра имеет 5 значений:

SN	Код и описание
1	1xx: Informational Это означает, что запрос получен и процесс продолжается.
2	2xx: Success Это означает, что действие было успешно получено, понято и принято.
3	3xx: Redirection Это означает, что для выполнения запроса необходимо предпринять дальнейшие действия.
4	4xx: Client Error Это означает, что запрос содержит неверный синтаксис или не может быть выполнен.
5	5xx: Server Error Серверу не удалось выполнить явно действительный запрос

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

Поля заголовка ответа

Мы изучим General-header и Entity-header в отдельной главе, когда будем изучать поля заголовка HTTP. А пока давайте проверим, что такое поля заголовка ответа.

Поля заголовка ответа позволяют серверу передавать дополнительную информацию об ответе, которую нельзя поместить в строку состояния. Эти поля заголовка предоставляют информацию о сервере и о дальнейшем доступе к ресурсу, идентифицированному Request-URI.

Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate

Вы можете ввести свои настраиваемые поля, если собираетесь написать собственный веб-клиент и сервер.

Примеры сообщений ответа

Теперь давайте соберем все это вместе, чтобы сформировать HTTP-ответ на запрос на выборку. hello.htm страница с веб-сервера, запущенного на сайте tutorialspoint.com

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Ниже приведен пример сообщения HTTP-ответа, показывающего состояние ошибки, когда веб-сервер не может найти запрошенную страницу:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

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

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

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

SN	Метод и описание
1	GET Метод GET используется для получения информации с заданного сервера с использованием заданного URI. Запросы, использующие GET, должны только извлекать данные и не должны иметь никакого другого влияния на данные.
2	HEAD То же, что GET, но передает только строку состояния и раздел заголовка.
3	POST Запрос POST используется для отправки данных на сервер, например информации о клиенте, загрузки файлов и т. Д., С использованием HTML-форм.
4	PUT Замените все текущие представления целевого ресурса загруженным контентом.
5	DELETE Удалите все текущие представления целевого ресурса, заданные URI.
6	CONNECT Установите туннель к серверу, идентифицированному заданным URI.
7	OPTIONS Опишите варианты коммуникации для целевого ресурса.
8	TRACE Выполните тест обратной связи для сообщений на пути к целевому ресурсу.

GET метод

Запрос GET извлекает данные с веб-сервера, указывая параметры в части URL-адреса запроса. Это основной метод, используемый для поиска документов. Ниже приведен простой пример, в котором для получения hello.htm используется метод GET:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Ниже будет ответ сервера на указанный выше запрос GET:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEAD метод

Метод HEAD функционально похож на GET, за исключением того, что сервер отвечает строкой ответа и заголовками, но без тела объекта. Ниже приведен простой пример, который использует метод HEAD для получения информации заголовка о hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Ниже будет ответ сервера на указанный выше запрос GET:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

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

Метод POST

Метод POST используется, когда вы хотите отправить некоторые данные на сервер, например обновление файла, данные формы и т. Д. Ниже приведен простой пример, который использует метод POST для отправки данных формы на сервер, которые будут обрабатываться process.cgi и, наконец, будет возвращен ответ:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Серверный скрипт process.cgi обрабатывает переданные данные и отправляет следующий ответ:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

Метод PUT

Метод PUT используется, чтобы запросить сервер сохранить включенное тело объекта в месте, указанном по данному URL-адресу. Следующий пример запрашивает сервер для сохранения заданного тела объекта вhello.htm в корне сервера:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Сервер сохранит данное тело объекта в hello.htm файл и отправит клиенту следующий ответ:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

УДАЛИТЬ метод

Метод DELETE используется, чтобы запросить сервер удалить файл в местоположении, указанном данным URL. В следующем примере сервер запрашивает удаление данного файлаhello.htm в корне сервера:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

Сервер удалит указанный файл hello.htm и отправит клиенту следующий ответ:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

CONNECT метод

Метод CONNECT используется клиентом для установления сетевого подключения к веб-серверу через HTTP. В следующем примере запрашивается соединение с веб-сервером, работающим на хосте tutorialspoint.com:

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Соединение устанавливается с сервером, и клиенту отправляется следующий ответ:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

ОПЦИИ Метод

Метод OPTIONS используется клиентом, чтобы узнать, какие методы HTTP и другие параметры поддерживаются веб-сервером. Клиент может указать URL-адрес для метода OPTIONS или звездочку (*) для ссылки на весь сервер. В следующем примере запрашивается список методов, поддерживаемых веб-сервером на сайте tutorialspoint.com:

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

Сервер отправит информацию на основе текущей конфигурации сервера, например:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

Метод TRACE

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

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Сервер отправит следующее сообщение в ответ на вышеуказанный запрос:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Элемент Status-Code в ответе сервера представляет собой трехзначное целое число, где первая цифра Status-Code определяет класс ответа, а последние две цифры не имеют никакой роли категоризации. Первая цифра имеет 5 значений:

SN	Код и описание
1	1xx: Informational Это означает, что запрос получен и процесс продолжается.
2	2xx: Success Это означает, что действие было успешно получено, понято и принято.
3	3xx: Redirection Это означает, что для выполнения запроса необходимо предпринять дальнейшие действия.
4	4xx: Client Error Это означает, что запрос содержит неверный синтаксис или не может быть выполнен.
5	5xx: Server Error Серверу не удалось выполнить явно действительный запрос

Коды состояния HTTP являются расширяемыми, и приложения HTTP не обязаны понимать значение всех зарегистрированных кодов состояния. Ниже приведен список всех кодов состояния.

1xx: Информация

Сообщение:	Описание:
100 Продолжить	Только часть запроса была получена сервером, но, пока она не была отклонена, клиент должен продолжить выполнение запроса.
101 протокол переключения	Сервер переключает протокол

2xx: Успешно

Сообщение:	Описание:
200 ОК	Запрос в порядке
201 Создано	Запрос выполнен, и новый ресурс создан
202 Принято	Запрос принят в обработку, но обработка не завершена
203 Непроверенная информация	Информация в заголовке объекта берется из локальной или сторонней копии, а не с исходного сервера.
204 Нет содержимого	Код состояния и заголовок даны в ответе, но в ответе нет тела объекта.
205 Сбросить содержимое	Браузер должен очистить форму, используемую для этой транзакции, для дополнительного ввода.
206 Частичное содержимое	Сервер возвращает частичные данные запрошенного размера. Используется в ответ на запрос с указанием заголовка Range . Сервер должен указать диапазон, включенный в ответ, с заголовком Content-Range .

3xx: перенаправление

Сообщение:	Описание:
300 вариантов выбора	Список ссылок. Пользователь может выбрать ссылку и перейти в это место. Максимум пять адресов
301 перемещен навсегда	Запрошенная страница перемещена на новый URL
302 Найдено	Запрошенная страница временно перемещена на новый URL
303 См. Другое	Запрошенная страница может быть найдена по другому URL-адресу
304 Не изменено	Это код ответа на заголовок If-Modified-Since или If-None-Match , где URL-адрес не изменялся с указанной даты.
305 Использовать прокси	Доступ к запрошенному URL-адресу должен осуществляться через прокси-сервер, указанный в заголовке Location .
306 Не используется	Этот код использовался в предыдущей версии. Он больше не используется, но код зарезервирован
307 Временное перенаправление	Запрошенная страница временно перемещена на новый URL

4xx: ошибка клиента

Сообщение:	Описание:
ошибка 400, неверный запрос	Сервер не понял запрос
401 Неавторизованный	Запрошенная страница требует имени пользователя и пароля.
402 Требуется оплата	Вы пока не можете использовать этот код
403 Запрещено	Доступ к запрошенной странице запрещен
404 Не Найдено	Сервер не может найти запрошенную страницу
405 Метод не разрешен	Метод, указанный в запросе, не разрешен
406 неприемлемо	Сервер может генерировать только ответ, который не принят клиентом.
407 Требуется проверка подлинности прокси	Вы должны пройти аутентификацию на прокси-сервере, прежде чем этот запрос будет обработан
408 Тайм-аут запроса	Запрос занял больше времени, чем сервер был готов ждать
409 Конфликт	Запрос не может быть выполнен из-за конфликта
410 ушел	Запрошенная страница больше не доступна
411 Требуется длина	"Content-Length" не определено. Без него сервер не примет запрос
412 Ошибка предварительного условия	Предварительное условие, указанное в запросе, оценивается сервером как ложное
413 Запрос слишком большой объект	Сервер не примет запрос, потому что объект запроса слишком велик
414 Request-url Too Long	Сервер не примет запрос, потому что URL-адрес слишком длинный. Возникает при преобразовании запроса "post" в запрос "get" с длинной информацией запроса.
415 Неподдерживаемый тип носителя	Сервер не примет запрос, потому что тип носителя не поддерживается
416 Запрошенный диапазон не удовлетворяется	Запрошенный диапазон байтов недоступен и находится за пределами допустимого диапазона.
417 Ожидание не выполнено	Ожидание, указанное в поле заголовка запроса Expect, не может быть выполнено этим сервером.

5xx: ошибка сервера

Сообщение:	Описание:
500 - внутренняя ошибка сервера	Запрос не был выполнен. Сервер встретил непредвиденное условие
501 Не реализовано	Запрос не был выполнен. Сервер не поддерживает требуемую функциональность
502 Неверный шлюз	Запрос не был выполнен. Сервер получил недопустимый ответ от вышестоящего сервера.
сервис 503 недоступен	Запрос не был выполнен. Сервер временно перегружен или не работает
Ошибка 504 Время ответа сервера истекло	Время ожидания шлюза истекло
505 Версия HTTP не поддерживается	Сервер не поддерживает версию "http протокол"

General-header: Эти поля заголовка имеют общее применение как для сообщений запроса, так и для сообщений ответа.
Client Request-header: Эти поля заголовка применимы только для сообщений запроса.
Server Response-header: Эти поля заголовка применимы только для ответных сообщений.
Entity-header: Эти поля заголовка определяют метаинформацию о теле объекта или, если тело отсутствует

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

Кэш-контроль

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

Подключение

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

Connection : "Connection"

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

Connection: Closed

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

Connection: keep-alive

Свидание

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: no-cache

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

Трейлер

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

Trailer : field-name

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

Transfer-Encoding
Content-Length
Trailer

Передача-кодирование

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

Transfer-Encoding: chunked

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

Обновить

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

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

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

Через

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)

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

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

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

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

Принять

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

Accept: type/subtype [q=qvalue]

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

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

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

Accept-Charset

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

Accept-Charset: character_set [q=qvalue]

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

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

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

Принять-кодирование

Поле заголовка запроса 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, но ограничивает набор естественных языков, которые предпочтительны в качестве ответа на запрос. Ниже приводится общий синтаксис:

Accept-Language: language [q=qvalue]

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

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

Авторизация

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

Authorization : credentials

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

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

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

Cookie-файлы

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

Cookie: name=value

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

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

Ожидать

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

Expect : 100-continue | expectation-extension

Если сервер получает запрос, содержащий поле Expect, которое включает расширение ожидания, которое он не поддерживает, он должен ответить статусом 417 (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 используется с методом, чтобы сделать его условным. Этот заголовок запрашивает у сервера выполнение запрошенного метода, только если данное значение в этом теге совпадает с заданными тегами объекта, представленнымиETag. Ниже приводится общий синтаксис:

If-Match : entity-tag

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

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

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

If-Modified-Since

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

If-Modified-Since : HTTP-date

Пример поля:

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

Если-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 можно использовать с условным GET для запроса только той части сущности, которая отсутствует, если она не была изменена, и всей сущности, если она была изменена. Ниже приводится общий синтаксис:

If-Range : entity-tag | HTTP-date

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

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

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

Если-без изменений-с

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

If-Unmodified-Since : HTTP-date

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

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

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

Макс-нападающие

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

Max-Forwards : n

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

Max-Forwards : 5

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

Прокси-авторизация

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

Proxy-Authorization : credentials

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

Спектр

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

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

Значение first-byte-pos в спецификации byte-range-spec дает байтовое смещение первого байта в диапазоне. Значение last-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

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

Референт

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

Referer : absoluteURI | relativeURI

Вот простой пример:

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

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

TE

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

TE   : t-codings

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

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

Если значение поля TE пустое или поле TE отсутствует, то единственное кодирование передачи разбивается на блоки . Сообщение без кодирования передачи всегда приемлемо.

Пользователь-агент

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

User-Agent : product | comment

Пример:

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

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

Принять-диапазоны

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

Accept-Ranges  : range-unit | none

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

Accept-Ranges: bytes

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

Accept-Ranges: none

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

Возраст

Поле заголовка ответа Age передает оценку отправителя количества времени, прошедшего с момента создания ответа (или его повторной проверки) на исходном сервере. Ниже приводится общий синтаксис:

Age : delta-seconds

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

Age: 1030

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

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 отличается от Location тем, что Content-Location идентифицирует исходное местоположение объекта, заключенного в запросе.

Прокси-аутентификация

Поле заголовка ответа Proxy-Authenticate должно быть включено как часть ответа 407 (требуется проверка подлинности прокси). Ниже приводится общий синтаксис:

Proxy-Authenticate  : challenge

Повторить после

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

Retry-After : HTTP-date | delta-seconds

Ниже приведены два простых примера:

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

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

Сервер

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

Server : product | comment

Вот простой пример:

Server: Apache/2.2.14 (Win32)

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

Set-Cookie

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

Set-Cookie: NAME=VALUE; OPTIONS

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

SN	Опции и описание
1	Comment=comment Этот параметр можно использовать для указания любого комментария, связанного с файлом cookie.
2	Domain=domain Атрибут Domain указывает домен, для которого действует cookie.
3	Expires=Date-time Дата истечения срока действия cookie. Если это поле пусто, срок действия cookie истечет, когда посетитель закроет браузер.
4	Path=path Атрибут Path указывает подмножество URL-адресов, к которым применяется этот файл cookie.
5	Secure Это указывает пользовательскому агенту возвращать cookie только при безопасном соединении.

Ниже приведен пример простого заголовка файла cookie, созданного сервером:

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

Варьировать

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

Vary : field-name

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

Vary: Accept-Language, Accept-Encoding

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

WWW-аутентификация

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

WWW-Authenticate : challenge

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

WWW-Authenticate: BASIC realm="Admin"

Заголовки объектов

Позволять

В поле « Разрешить заголовок объекта» перечислен набор методов, поддерживаемых ресурсом, идентифицированным Request-URI. Ниже приводится общий синтаксис:

Allow : Method

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

Allow: GET, HEAD, PUT

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

Content-Encoding

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

Content-Encoding : content-coding

Кодирование содержимого - это характеристика объекта, идентифицированного Request-URI. Вот простой пример:

Content-Encoding: gzip

Если кодирование содержимого объекта в сообщении запроса неприемлемо для исходного сервера, сервер должен ответить кодом состояния 415 (неподдерживаемый тип носителя).

Content-Language

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

Content-Language : language-tag

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

Content-Language: mi, en

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

Content-Length

Поле заголовка объекта Content-Length указывает размер тела объекта в десятичном числе OCTET, отправленных получателю, или, в случае метода 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  : 8c2d46911f3f5a326455f0ed7a8ed3b3

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

Content-Range

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

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

Примеры значений byte-content-range-spec, предполагая, что объект содержит всего 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 / 1.1 включает ряд элементов, предназначенных для работы кеширования.

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

Основные механизмы кеширования в HTTP / 1.1 - это неявные директивы для кешей, где сервер указывает время истечения срока действия и валидаторы. Мы используемCache-Control заголовок для этой цели.

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

URL-адреса HTTP могут быть отправлены через Интернет только с использованием набора символов ASCII , который часто содержит символы вне набора ASCII. Поэтому эти небезопасные символы необходимо заменить на% за которыми следуют две шестнадцатеричные цифры.

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

ASCII	Условное обозначение	Замена
<32		Кодировать с помощью% xx, где xx - шестнадцатеричное представление символа.
32	пространство	+ или% 20
33	!	% 21
34	"	% 22
35 год	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41 год	)	% 29
42	*	*
43 год	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	<	% 3C
61	знак равно	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	А	А
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	г	г
72	ЧАС	ЧАС
73	я	я
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	О	О
80	п	п
81 год	Q	Q
82	р	р
83	S	S
84	Т	Т
85	U	U
86	V	V
87	W	W
88	Икс	Икс
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	а	а
98	б	б
99	c	c
100	d	d
101	е	е
102	ж	ж
103	г	г
104	час	час
105	я	я
106	j	j
107	k	k
108	л	л
109	м	м
110	п	п
111	о	о
112	п	п
113	q	q
114	р	р
115	s	s
116	т	т
117	ты	ты
118	v	v
119	ш	ш
120	Икс	Икс
121	y	y
122	z	z
123	{	%7B
124	\|	%7C
125	}	%7D
126	~	%7E
127		%7F
> 127		Encode with %xx where xx is the hexadecimal representation of the character

HTTP is used for a communication over the internet, so application developers, information providers, and users should be aware of the security limitations in HTTP/1.1. This discussion does not include definitive solutions to the problems mentioned here but it does make some suggestions for reducing security risks.

Personal Information leakage

HTTP clients are often privy to large amounts of personal information such as the user's name, location, mail address, passwords, encryption keys, etc. So you should be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources.

All the confidential information should be stored at server side in encrypted form.
Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes.
Proxies which serve as a portal through a network firewall should take special precautions regarding the transfer of header information that identifies the hosts behind the firewall.
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it should not be transmitted without the user being able to disable, enable, and modify the contents of the field.
Clients should not include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Authors of services which use the HTTP protocol should not use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI

File and path names based attack

The document should be restricted to the documents returned by HTTP requests to be only those that were intended by the server administrators.

For example, UNIX, Microsoft Windows, and other operating systems use .. as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server.

DNS Spoofing

Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. So clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.

If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS. If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes.

Location Headers and Spoofing

If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.

Authentication Credentials

Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials which is a big security risk.

There are a number of work- arounds to parts of this problem, and so its is recommended to make the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem.

Proxies and Caching

HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers.

Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information.

Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Therefore, cache contents should be protected as sensitive information.

Example 1

HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com

Client request

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Example 2

HTTP request to fetch t.html page which does not exist on the web server running on tutorialspoint.com

Client request

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Example 3

HTTP request to fetch hello.htm page from the web server running on tutorialspoint.com, but request goes with wrong HTTP version:

Client request

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Server response

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Example 4

HTTP request to post form data to process.cgi CGI page on a web server running on tutorialspoint.com. Server returns passed name after setting them as cookies:

Client request

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Server response

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>