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

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

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

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

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

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

  • HTTP не зависит от носителя: это означает, что любой тип данных может быть отправлен по HTTP, если и клиент, и сервер знают, как обрабатывать содержимое данных. Это необходимо как для клиента, так и для сервера, чтобы указать тип контента, используя соответствующий MIME-тип.

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

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

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

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

Архитектура HTTP

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

клиент

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

сервер

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

HTTP - Параметры

Эта глава собирается перечислить некоторые важные параметры протокола 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 ]]

Здесь, если порт пуст или не задан, порт 80 предполагается для HTTP, а пустой abs_path эквивалентен abs_path из "/". Символы, отличные от зарезервированных и небезопасных наборов, эквивалентны их кодировке ""% "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 , чтобы обеспечить открытую и расширяемую типизацию данных и согласование типов. Все значения типа мультимедиа зарегистрированы в Центре назначенных номеров Интернета (IANA). Ниже приведен общий синтаксис для указания типа мультимедиа:

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

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

пример

Accept: image/gif

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

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

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

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

пример

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

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

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

HTTP - сообщения

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

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

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

 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 Request и HTTP Response соответственно. А пока давайте посмотрим примеры строки запуска в случае запроса и ответа:

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: Эти поля заголовка имеют общую применимость как для сообщений запроса, так и для ответов.

  • Заголовок запроса: эти поля заголовка применимы только для сообщений запроса.

  • Заголовок ответа: эти поля заголовка применимы только для ответных сообщений.

  • Заголовок объекта : Эти поля заголовка определяют метаинформацию о теле объекта или, если тело отсутствует

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

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-клиент отправляет 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.

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

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

SN Метод и описание
1 ПОЛУЧИТЬ
Метод GET используется для получения информации с данного сервера с использованием заданного URI. Запросы, использующие GET, должны только извлекать данные и не должны оказывать никакого другого влияния на данные.
2 ГОЛОВА
То же, что и GET, но только перенос строки состояния и раздела заголовка.
3 ПОЧТА
POST-запрос используется для отправки данных на сервер, например, информация о клиенте, загрузка файла и т. Д. С использованием HTML-форм.
4 ПОЛОЖИЛ
Замените все текущие представления целевого ресурса загруженным контентом.
5 УДАЛЯТЬ
Удалить все текущие представления целевого ресурса, заданного URI.
6 CONNECT
Установите туннель к серверу, идентифицированному данным URI.
7 ПАРАМЕТРЫ
Опишите параметры связи для целевого ресурса.
8 TRACE
Выполните проверку обратной связи по пути к целевому ресурсу.

Request-URI

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

Request-URI = "*" | absoluteURI | abs_path | authority
SN Метод и описание
1 Звездочка * используется, когда HTTP-запрос относится не к конкретному ресурсу, а к самому серверу, и разрешен только в том случае, если используемый метод не обязательно применяется к ресурсу. Например:

ОПЦИИ * HTTP / 1.1

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

ПОЛУЧИТЕ 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
Хост: www.w3.org

Обратите внимание, что абсолютный путь не может быть пустым; если ни один не присутствует в исходном URI, он ДОЛЖЕН быть задан как "/" (корень сервера)

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

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

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

  • Accept-Charset

  • Accept-Encoding

  • Accept-Language

  • авторизация

  • ожидать

  • Из

  • хозяин

  • If-Match

  • If-Modified-Since

  • If-None-Match

  • If-Range

  • Если-Unmodified-С

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

  • Proxy-Authorization

  • Ассортимент

  • Referer

  • TE

  • User-Agent

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

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

Теперь давайте соберем все вместе, чтобы сформировать HTTP-запрос для получения страницы hello.htm с веб-сервера, работающего на it-brain.online

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

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

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.it-brain.online
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 сообщает серверу, что передаваемые данные являются простыми данными веб-формы, а длина будет фактической длиной данных, помещенных в тело сообщения. В следующем примере показано, как передать XML плана на свой веб-сервер:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.it-brain.online
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 - Ответы

После получения и интерпретации сообщения запроса сервер отвечает сообщением 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-сообщении.

Сообщение Status-Line

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

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

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

Версия HTTP

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

HTTP-Version = HTTP/1.1

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

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

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

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

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

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

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

  • Accept-Ranges

  • Возраст

  • ETag

  • Место расположения

  • Proxy-Authenticate

  • Retry-After

  • сервер

  • изменяться

  • WWW-Authenticate

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

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

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

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 - Методы

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

SN Метод и описание
1 ПОЛУЧИТЬ
Метод GET используется для получения информации с данного сервера с использованием заданного URI. Запросы, использующие GET, должны только извлекать данные и не должны оказывать никакого другого влияния на данные.
2 ГОЛОВА
То же, что и GET, но только перенос строки состояния и раздела заголовка.
3 ПОЧТА
POST-запрос используется для отправки данных на сервер, например, информация о клиенте, загрузка файла и т. Д. С использованием HTML-форм.
4 ПОЛОЖИЛ
Замените все текущие представления целевого ресурса загруженным контентом.
5 УДАЛЯТЬ
Удалить все текущие представления целевого ресурса, заданного URI.
6 CONNECT
Установите туннель к серверу, идентифицированному данным URI.
7 ПАРАМЕТРЫ
Опишите параметры связи для целевого ресурса.
8 TRACE
Выполните проверку обратной связи по пути к целевому ресурсу.

ПОЛУЧИТЬ метод

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

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.it-brain.online
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 функционально похож на GET, за исключением того, что сервер отвечает строкой ответа и заголовками, но без тела объекта. Ниже приведен простой пример, который использует метод HEAD для получения информации заголовка о hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.it-brain.online
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.it-brain.online
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.it-brain.online
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.it-brain.online
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 используется клиентом для установления сетевого подключения к веб-серверу по HTTP. В следующем примере запрашивается соединение с веб-сервером, работающим на хосте it-brain.online:

CONNECT www.it-brain.online 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 или звездочку (*) для ссылки на весь сервер. В следующем примере запрашивается список методов, поддерживаемых веб-сервером, работающим на it-brain.online:

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.it-brain.online
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.it-brain.online
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

HTTP - коды состояния

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

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

Коды состояния 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 длина требуется «Длина содержимого» не определена. Сервер не примет запрос без него
412 Не выполнено предварительное условие Предварительное условие, указанное в запросе, оценивается сервером как ложное
413 Запросить объект слишком большой Сервер не примет запрос, потому что объект запроса слишком велик
414 URL запроса слишком длинный Сервер не примет запрос, потому что URL слишком длинный. Происходит при преобразовании запроса «post» в запрос «get» с длинной информацией о запросе
415 неподдерживаемый тип носителя Сервер не примет запрос, потому что тип носителя не поддерживается
416 Запрошенный диапазон не удовлетворяет Запрашиваемый диапазон байтов недоступен и находится за пределами.
417 Ожидание не удалось Ожидание, данное в поле заголовка запроса Expect, не может быть удовлетворено этим сервером.

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

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

HTTP - поля заголовка

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

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

  • Заголовок запроса клиента: эти поля заголовка применимы только для сообщений запроса.

  • Заголовок ответа сервера. Эти поля заголовка применимы только для ответных сообщений.

  • Заголовок объекта : Эти поля заголовка определяют метаинформацию о теле объекта или, если тело отсутствует

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

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

Поле общего заголовка Cache-Control используется для указания директив, которым ДОЛЖНЫ подчиняться все системы кэширования. Ниже приводится синтаксис:

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

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

Cache-control: no-cache

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

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

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

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

Дата

Все 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

Здесь первый формат является наиболее предпочтительным.

Pragma

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

Pragma: no-cache

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

трейлер

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

Trailer : field-name

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

  • Transfer-Encoding

  • Content-Length

  • трейлер

Transfer-Encoding

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

Transfer-Encoding: chunked

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

Обновить

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

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)

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

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

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

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 / xc - предпочтительные типы носителей, но если они не существуют, отправьте сущность 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-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=qvalue]

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

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

авторизация

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

Authorization : credentials

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

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

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

печенье

Значение поля заголовка запроса 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 [ ":" port ] ;

Хост без информации о заднем порте подразумевает порт по умолчанию, равный 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: *

Если ни один из тегов объекта не совпадает или если задано «*», а текущий объект не существует, сервер не должен выполнять запрошенный метод и должен возвращать ответ 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

Если ни один из тегов объекта не совпадает или если задано «*», а текущий объект не существует, сервер не должен выполнять запрошенный метод и должен возвращать ответ 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-Unmodified-Since отсутствовал. Например:

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

Max-Forwards : 5

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

Proxy-Authorization

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

Proxy-Authorization : credentials

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

Ассортимент

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

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

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

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

Referer

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

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 передает оценку отправителя количества времени, прошедшего с того момента, как ответ (или его повторная проверка) был сгенерирован на исходном сервере. Ниже приводится общий синтаксис:

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

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

Proxy-Authenticate  : challenge

Retry-After

Поле заголовка ответа 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 Комментарий = комментарий
Эта опция может использоваться для указания любого комментария, связанного с cookie.
2 Домен = домен
Атрибут Домен указывает домен, для которого действителен файл cookie.
3 Истекает = Дата-время
Дата истечения срока действия cookie. Если это поле пустое, срок действия файла cookie истечет, когда посетитель выйдет из браузера.
4 Path = путь
Атрибут Path указывает подмножество URL-адресов, к которым применяется этот файл cookie.
5 Безопасный
Это дает указание агенту пользователя возвращать 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-Authenticate

Поле заголовка ответа WWW-Authenticate должно быть включено в ответные сообщения 401 (неавторизованный). Значение поля состоит по меньшей мере из одного запроса, который указывает схему (ы) аутентификации и параметры, применимые к 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 (Unsupported Media Type).

Content-Language

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

Content-Language : language-tag

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

Content-Language: mi, en

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

Content-Length

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

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 обычно используется для распределенных информационных систем, где производительность может быть улучшена за счет использования кэшей ответов. Протокол HTTP / 1.1 включает в себя ряд элементов, предназначенных для обеспечения работы кэширования.

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

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

Заголовок Cache-Control позволяет клиенту или серверу передавать различные директивы в запросах или ответах. Эти директивы обычно переопределяют алгоритмы кэширования по умолчанию. Директивы кэширования указываются в списке через запятую. Например:

Cache-control: no-cache

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

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

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

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

HTTP - кодировка URL

HTTP-URL-адреса могут отправляться только через Интернет с использованием набора символов 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 В В
67 С С
68 D D
69 Е Е
70 F F
71 грамм грамм
72 ЧАС ЧАС
73 я я
74 J J
75 К К
76 L L
77 M M
78 N N
79 О О
80 п п
81 Q Q
82 р р
83 S S
84 T T
85 U U
86 В В
87 W W
88 Икс Икс
89 Y Y
90 Z Z
91 [ % 5B
92 \ % 5C
93 ] % 5D
94 ^ % 5E
95 _ _
96 ` % 60
97
98 б б
99 с с
100 d d
101 е е
102 е е
103 грамм грамм
104 час час
105 я я
106 J J
107 К К
108 L L
109 м м
110 N N
111 о о
112 п п
113 Q Q
114 р р
115 s s
116 T T
117 U U
118 v v
119 вес вес
120 Икс Икс
121 Y Y
122 Z Z
123 { % 7B
124 | % 7C
125 } % 7D
126 ~ % 7E
127 % 7F
> 127 Кодировать с% xx, где xx - шестнадцатеричное представление символа

HTTP - Безопасность

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

Утечка личной информации

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

  • Вся конфиденциальная информация должна храниться на стороне сервера в зашифрованном виде.

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

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

  • Информация, отправляемая в поле «От», может противоречить интересам пользователя в отношении конфиденциальности или политике безопасности их сайта, и, следовательно, она не должна передаваться без возможности пользователя отключать, включать и изменять содержимое поля.

  • Клиенты не должны включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.

  • Авторам сервисов, которые используют протокол HTTP, не следует использовать формы на основе GET для представления конфиденциальных данных, поскольку это приведет к тому, что эти данные будут закодированы в Request-URI

Атака на основе имен файлов и путей

Документ должен быть ограничен документами, возвращаемыми по HTTP-запросам, чтобы они были только теми, которые были предназначены администраторами сервера.

Например, UNIX, Microsoft Windows и другие операционные системы используют .. в качестве компонента пути для указания уровня каталога выше текущего. В такой системе HTTP-сервер ДОЛЖЕН запретить любую такую конструкцию в Request-URI, если в противном случае он разрешил бы доступ к ресурсу, который не предназначен для доступа через HTTP-сервер.

DNS спуфинг

Клиенты, использующие HTTP, в значительной степени зависят от службы доменных имен и, таким образом, обычно подвержены атакам безопасности, основанным на преднамеренной неправильной ассоциации IP-адресов и DNS-имен. Таким образом, клиенты должны быть осторожны, предполагая, что IP-адрес / DNS-имя сохраняются.

Если клиенты HTTP кэшируют результаты поиска имен хостов, чтобы добиться улучшения производительности, они должны соблюдать информацию TTL, сообщаемую DNS. Если клиенты HTTP не соблюдают это правило, они могут быть подделаны при изменении IP-адреса ранее посещенного сервера.

Расположение заголовков и спуфинг

Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, то он ДОЛЖЕН проверить значения заголовков Location и Content-Location в ответах, которые генерируются под управлением указанных организаций, чтобы убедиться, что они не пытаются сделать недействительными ресурсы, по которым у них нет полномочий.

Учетные данные аутентификации

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

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

Прокси и кеширование

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

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

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

HTTP - Примеры сообщений

Пример 1

HTTP-запрос на получение страницы hello.htm с веб-сервера, работающего на it-brain.online

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

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

Ответ сервера

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>

Пример 2

HTTP-запрос на получение t.html- страницы, которой нет на веб-сервере, работающем на it-brain.online

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

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

Ответ сервера

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>

Пример 3

HTTP-запрос на получение страницы hello.htm с веб-сервера, работающего на it-brain.online , но запрос идет с неверной версией HTTP:

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

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

Ответ сервера

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>

Пример 4

HTTP-запрос на размещение данных формы на CGI-странице process.cgi на веб-сервере, работающем на it-brain.online . Сервер возвращает переданное имя после установки их в виде файлов cookie:

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

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.it-brain.online
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

Ответ сервера

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=it-brain.online;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>