Учебники

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

Август 19, 2018

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

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

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

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

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

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

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

    • 

  • 

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

    • 

  • 

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

    • 

  • 

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

    • 



  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, он ДОЛЖЕН быть задан как "/" (корень сервера) 








  ОПЦИИ * HTTP / 1.1 


  ПОЛУЧИТЕ http://www.w3.org/pub/WWW/TheProject.html HTTP / 1.1 


  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 
    

    • 



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


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 сообщает серверу, что передаваемые данные являются простыми данными веб-формы, а длина будет фактической длиной данных, помещенных в тело сообщения.  В следующем примере показано, как передать 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 - Ответы 


  После получения и интерпретации сообщения запроса сервер отвечает сообщением 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 представляет собой трехзначное целое число, где первая цифра Status-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 
    

    • 



  Accept-Ranges 


  Возраст 


  ETag 


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


  Proxy-Authenticate 


  Retry-After 


  сервер 


  изменяться 


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


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



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

    • 

  • 

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

    • 

  • 

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

    • 

  • 

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

    • 



  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 


  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



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


 Реферер: 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 
    

    • 



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


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


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


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


  Клиенты не должны включать поле заголовка 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 с веб-сервера, запущенного на 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



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


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, которая не существует на веб-сервере, работающем на tutorialspoint.com 


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


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



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


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 с веб-сервера, работающего на tutorialspoint.com , но запрос идет с неверной версией HTTP: 


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


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



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


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 на веб-сервере, работающем на tutorialspoint.com .  Сервер возвращает переданное имя после установки их в виде файлов cookie:
71
Share: