Разное

Http методы протокола: Тема 7: Методы HTTP запросов. Определение методов HTTP (HTTP Method Definitions).

Содержание

Тема 7: Методы HTTP запросов. Определение методов HTTP (HTTP Method Definitions).

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы изучим с тобой HTTP методы. Для начала мы с тобой разберемся с видами HTTP методов, потом разберем безопасные HTTP методы, выделим идемпотентные методы. После чего я перечислю все HTTP методы с их кратким описание, а далее мы разберем каждый метод в отдельности. Надеюсь, примеры, используемые в данной публикации помогут тебе понять как работают все эти методы: GET, POST, HEAD, CONNECT, PUT, DELETE, OPTIONS и TRACE. Как всегда, если что-то непонятно или есть какие-то дополнения или заметил неточность — не стесняйся написать комментарий.

Определение методов HTTP (HTTP Method Definitions). Описание методов HTTP запросов

 

Виды HTTP методов запроса

Содержание статьи:

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

Безопасные HTTP методы и идемпотентные HTTP методы запросов

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

Безопасные HTTP методы (Safe method HTTP)

На данный момент принято соглашение о том, что HTTP методы GET и HEAD никогда не должны иметь иного значения, кроме загрузки, поэтому данные HTTP методы нужно рассматривать, как безопасные, это требование HTTP. Поэтому ваш браузер, когда используются методы POST, PUT или DELETE предупреждает вас о том, что может произойти потенциально опасное действие и спрашивает: нужно ли его выполнить.

Идемпотентные HTTP методы (Idempotent Methods HTTP)

Я уже вкратце объяснил суть идемпотентных HTTP методов: при использование таких методов побочные эффекты одинаковы как в случае однократного запроса, так и в случае многократного повторения одного и того же запроса, т.е. нагрузка одинакова, но HTTP ответ от сервера может поступать каждый раз разный. К идемпотентным методам относятся следующие HTTP методы: GET, HEAD, PUT и DELETE. Так же эффектом идемпотентности обладают HTTP методы OPTIONS и TRACE.

Краткий обзор HTTP методов

Давайте перечислим все методы HTTP протокола и дадим им краткое описание. Для удобства сведем HTTP методы в таблицу

Номер HTTP метод и его описание
1 HTTP метод GET
Метода GET в HTTP используется для получения информации от сервера по заданному URI (URI в HTTP). Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
2 HTTP метод HEAD
HTTP метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
3 HTTP метод POST
HTTP метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
4 HTTP метод PUT
HTTP метод PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.
5 HTTP метод DELETE 
HTTP метод DELETE удаляет указанный в URI ресурс.
6 HTTP метод CONNECT
HTTP метод CONNECT преобразует существующее соединение в тоннель.
7 HTTP метод OPTIONS
HTTP метод OPTIONS используется для получения параметров текущего HTTP соединения.
8 HTTP метод TRACE
HTTP метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.

Мы вкратце рассмотрели все HTTP методы и дали им короткую характеристику. Давайте теперь более подробно остановимся на каждом из HTTP методов и приведем несколько примеров использования HTTP методов.

Описание HTTP метода GET. Пример использования HTTP метода GET

HTTP метод GET позволяет получать информацию с HTTP сервера. Информация, получаемая от сервера может быть любой, главное, чтобы она была в форме HTTP объекта, доступ к информации при использовании метода GET осуществляется через URI. Часто бывает так, что HTTP  метод GET обращается к какому-то коду, а не к конкретной страницы (все CMS генерируют контент налету), поэтому метод GET работает так, что мы получаем не исходный код, который генерирует текст, а сам текст.

HTTP метод GET бывает двух видов: условный метод GET и частичный метод GET. Давайте сперва посмотрим на условный метод GET. Когда используется условный HTTP метод GET, то к HTTP сообщению добавляются следующие поля заголовков: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Значение таких полей является какое-либо условие и если это условие выполняется, то происходит передача объекта, который хранится по указанному URI, если же условие не выполняется, то и сервер не передает никаких данных. Условный HTTP метод GET предназначен для уменьшения нагрузки на сеть.

Давайте теперь посмотрим на особенности работы частичного HTTP метода GET. Особенность частичного метода GET заключается в том, что в его заголовке присутствует поле Range. Когда используется частичные метод GET полезная информация, предназначенная для человека передается кусками, после чего она из этих кусков собирается. Не напоминает ли это вам скачивание файлов по HTTP протоколу, когда мы можем остановить загрузку, отключить браузер, потом опять включить браузер и закачка будет происходить ровно с того места, где она была приостановлена. Не стоит забывать, что поля заголовков — это параметры HTTP протокола, которые определяют, как будут работать клиент и сервер.

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

GET /hello.htm HTTP/1.1

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

Host: www.example.com

Accept-Language: ru-ru

Accept-Encoding: gzip, deflate

Connection: Keep-Alive



GET /hello.htm HTTP/1.1

 

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

 

Host: www.example.com

 

Accept-Language: ru-ru

 

Accept-Encoding: gzip, deflate

 

Connection: Keep-Alive

На такой HTTP запрос сервер ответит (читай про HTTP ответы) примерно следующее:

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>

<h2>Hello, World!</h2>

</body>

</html>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

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>

 

<h2>Hello, World!</h2>

 

</body>

 

</html>

Мы рассмотрели самый часто используемый HTTP метод GET, давайте теперь посмотрим на второй по популярности HTTP метод – метод POST.

Описание HTTP метода POST. Пример использования HTTP метода POST

HTTP метод POST является вторым по использованию в Интернете и нужен для того, чтобы отправлять данные на сервер. HTTP метод POST позволяет отправлять данные на сервер. Разработчики ввели метод POST в HTTP  стандарт, чтобы клиенты могли:

  • оставлять сообщения на различных Интернет-ресурсах;
  • передавать информацию о себе, заполняя HTML формы;

То, как будет работать метод POST определяется исключительно на стороне сервера и обычно зависит от запрашиваемого URI. Если сравнить URI, которому обращается клиент и сообщение, которое он хочет отправить с файловой системой, то URI – это папка, а сообщение клиента – это файл, который лежит в папке.

В результате выполнения HTTP метода POST сервер не обязательно в качестве ресурса выдает URI, код состояния сервера при использовании HTTP метода POST может быть 200 (в этом случае вы получите какой-либо ресурс), либо 204 (в этом случае вы не получите никакого содержимого). Ответы сервера на метод POST не кэшируются, но это можно сделать принудительно, если использовать поле Cache-Control или Expires в заголовке.

Давайте приведем пример использования HTTP метода POST:

POST /cgi-bin/process.cgi HTTP/1.1

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

Host: www.example.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://example.com/»>Ваше сообщение</string>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

POST /cgi-bin/process.cgi HTTP/1.1

 

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

 

Host: www.example.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://example.com/»>Ваше сообщение</string>

Тогда HTTP сервер ответит примерно следующее:

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>

<h2>Вах, братка! Твой запрос успэшно сдэлан!</h2>

</body>

</html>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

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>

 

<h2>Вах, братка! Твой запрос успэшно сдэлан!</h2>

 

</body>

 

</html>

Мы рассмотрели HTTP метод POST, давайте теперь посмотрим на HTTP метод HEAD, который очень похож на метод GET.

Описание HTTP метода HEAD. Пример использования HTTP метода HEAD

HTTP метод HEAD работает точно так же, как и метод GET, с той лишь разницей, что сервер в ответ не посылает тело HTTP сообщения. Все заголовки ответа при запросе клиента с использованием метода HEAD идентичны тем заголовкам, которые бы были, если бы использовался метод GET. Обычно HTTP метод HEAD используется для получения метаинформации об объекте без пересылки тела HTTP сообщения. Метод HEAD часто используется для тестирования HTTP соединений и достижимости узлов и ресурсов, так как нет необходимости гонять по сети содержимое, тестирование HTTP методом HEAD производится гораздо быстрее. Сервер может кэшировать свои ответы на запросы с методом HEAD. Еще одно применение метода HEAD заключается в обсуждение HTTP содержимого.

Давайте лучше самостоятельно напишем HTTP запрос с методом HEAD и посмотрим, какой ответ мы можем получить от сервера:

HEAD /hello.htm HTTP/1.1

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

Host: www.example.com

Accept-Language: ru-ru

Accept-Encoding: gzip, deflate

Connection: Keep-Alive



HEAD /hello.htm HTTP/1.1

 

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

 

Host: www.example.com

 

Accept-Language: ru-ru

 

Accept-Encoding: gzip, deflate

 

Connection: Keep-Alive

На такой HTTP запрос сервер ответит примерно следующее:

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


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

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

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

Описание HTTP метода OPTIONS. Пример использования HTTP метода OPTIONS

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

Сервер отвечает на запрос с методом OPTIONS только опциями соединения, например он посылает поля заголовков Allow, но не пошлет Content-Type, ответы сервера на запросы с методом OPTIONS не кэшируются. Если в качестве URI указана звездочка «*», то параметры соединения передаются для сервера в целом, а не для какого-то конкретного URL. Этот метод не самый безопасный для HTTP сервера, поэтому зачастую клиенты его не могут применять из-за настроек безопасности.

Давайте посмотрим пример запроса с HTTP методом OPTIONS:

OPTIONS * HTTP/1.1

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



OPTIONS * HTTP/1.1

 

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

А примерно так ответит сервер на запрос с методом OPTIONS

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



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

Мы подробно рассмотрели особенности работы HTTP метода OPTIONS. Давайте перейдем к рассмотрению метода PUT.

Описание HTTP метода PUT. Пример использования HTTP метода PUT

HTTP метод PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI. То есть HTTP запрос с методом PUT уже заранее содержат в теле сообщения какой-то объект, который должен быть сохранен на сервере по адресу, который указан в URI. Но если по данному URI уже есть какие-либо данные, то данные, поступающие из запроса с методом PUT, считаются модификацией. Если запрос с HTTP методом PUT обращается к не существующему URI, то сервер создает новый URI и сообщает об этом клиенту. Если ресурс успешно создан по средствам метода PUT, то сервер возвращает ответ с кодом состояния 201, если ресурс успешно модифицирован, то сервер вернет код 200, либо 204. Если по каким-либо причинам серверу не удается создать ресурс, то в ответ клиенту он высылает описание проблемы, возможно, с кодом ошибки клиента или кодом ошибки сервера.

Ответы сервера на HTTP метод PUT не кэшируются. Стоит обратить внимание, что метод POST и метод PUT выполняют совершенно разные операции. Метод POST обращается к ресурсу (странице или коду), которая содержит механизмы обработки сообщения метода POST, а вот метод PUT создает какой-то объект по URI, указанному в сообщение с HTTP методом PUT.

Давайте теперь посмотрим пример работы HTTP метода PUT:

PUT /hello.htm HTTP/1.1

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

Host: www.example.com

Accept-Language: ru-ru

Connection: Keep-Alive

Content-type: text/html

Content-Length: 182

 

<html>

<body>

<h2>Hello, World!</h2>

</body>

</html>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

PUT /hello.htm HTTP/1.1

 

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

 

Host: www.example.com

 

Accept-Language: ru-ru

 

Connection: Keep-Alive

 

Content-type: text/html

 

Content-Length: 182

 

 

 

<html>

 

<body>

 

<h2>Hello, World!</h2>

 

</body>

 

</html>

Сервер в этом случае сохранит файл hello.htm, он будет доступен по указанному URI, в самом файле будет находиться HTML код, который указан в теле сообщения, а в ответ сервер отправит примерно следующее:

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>

<h2>The file was created.</h2>

</body>

</html>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

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>

 

<h2>The file was created.</h2>

 

</body>

 

</html>

Мы рассмотрели всё, что качается метода PUT. Давайте теперь перейдем к рассмотрению HTTP метода DELETE

Описание HTTP метода DELETE. Пример использования HTTP метода DELETE

HTTP метод DELETE используется для удаления ресурса, указанного в URI. Действие метода DELETE может быть отменено вмешательством администратора HTTP сервера или программным кодом. Даже в том случае, когда сервер отправит вам код 200 после обработки метода DELETE, это не будет означать, что ресурс удален, это всего лишь означает, что сервер вас понял и обработал ваш запрос. Ответы сервера на HTTP метод DELETE не кэшируются.

Давайте теперь рассмотрим пример HTTP запроса, который использует метод DELETE:

DELETE /hello.htm HTTP/1.1

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

Host: www.example.com

Accept-Language: ru-ru

Connection: Keep-Alive



DELETE /hello.htm HTTP/1.1

 

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

 

Host: www.example.com

 

Accept-Language: ru-ru

 

Connection: Keep-Alive

Сервер  может ответить на сообщение клиента с методом DELETE примерно следующее:

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>

<h2>URL deleted.</h2>

</body>

</html>


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

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>

 

<h2>URL deleted.</h2>

 

</body>

 

</html>

Мы разобрали HTTP метод DELETE, давайте теперь рассмотрим метод TRACE.

Описание HTTP метода TRACE. Пример использования HTTP метода TRACE

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

HTTP метод TRACE применяется для диагностики, он позволяет видеть клиенту, что происходит в каждом звене цепочки между компьютером клиента и конечным получателем, для этого существует специальное поле Via. Ответы сервера на метод TRACE не кэшируются.

Давайте теперь посмотрим пример HTTP метода TRACE:

TRACE / HTTP/1.1

Host: www.example.com

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



TRACE / HTTP/1.1

 

Host: www.example.com

 

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

На такой HTTP запрос сервер может ответить так:

HTTP/1.1 200 OK

Date: Mon, 27 Jul 2009 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Connection: close

Content-Type: message/http

Content-Length: 39

 

TRACE / HTTP/1.1

Host: www.example.com

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


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

HTTP/1.1 200 OK

 

Date: Mon, 27 Jul 2009 12:28:53 GMT

 

Server: Apache/2.2.14 (Win32)

 

Connection: close

 

Content-Type: message/http

 

Content-Length: 39

 

 

 

TRACE / HTTP/1.1

 

Host: www.example.com

 

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

Мы рассмотрели HTTP метод TRACE, давайте рассмотрим последний метод HTTP протокола – метод CONNECT.

Описание HTTP метода CONNECT. Пример использования HTTP метода CONNECT

HTTP метод CONNECT используется для преобразования HTTP соединения в прозрачный TCP/IP туннель.  Пожалуй, это всё, что можно сказать про HTTP метод CONNECT в контексте рассматриваемого протокола, разве что стоит добавить, что данный метод используется в основном для шифрования соединения (не путайте с кодировкой сообщений).

Давайте посмотрим пример использования HTTP метода CONNECT:

CONNECT www.example.com HTTP/1.1

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



CONNECT www.example.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)



HTTP/1.1 200 Connection established

 

Date: Mon, 27 Jul 2009 12:28:53 GMT

 

Server: Apache/2.2.14 (Win32)

На этом мы закончим рассмотрение HTTP методов и перейдем к другим темам.

Простым языком об HTTP / Хабр

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

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.


Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

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

Как отправить HTTP-запрос?

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

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

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

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

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

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

echo -en "GET / HTTP/1.1\r\nHost: alizar.habrahabr.ru\r\n\r\n" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

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

HTTP/Версия Код состояния Пояснение

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Sat, 08 Mar 2014 22:53:46 GMT
Content-Type: application/octet-stream
Content-Length: 7
Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT
Connection: keep-alive
Accept-Ranges: bytes

Wisdom

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.

Смотрите сами:

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 08 Mar 2014 22:29:53 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Keep-Alive: timeout=25
Location: http://habrahabr.ru/users/alizar/

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h2>302 Found</h2></center>
<hr><center>nginx</center>
</body>
</html>

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.

А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол SPDY (произносится как английское слово speedy, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.

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

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

Удачи и плодотворного обучения!

Типы HTTP-запросов и философия REST / Хабр

Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂

Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.

Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION,

где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).

Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.

Рассмотрим пример.

Запрос:

GET /index.php HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close

Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует

Ответ:

HTTP/1.0 200 OK
Server: nginx/0.6.31
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close

... САМА HTML-СТРАНИЦА ...

Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

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

  • GET — получение ресурса
  • POST — создание ресурса
  • PUT — обновление ресурса
  • DELETE — удаление ресурса

Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) — обязателен только GET, а также не указывает серверу, что он должен делать при получении запроса с тем или иным методом. А это значит, что сервер в ответ на запрос DELETE /index.php HTTP/1.1 не обязан удалять страницу index.php на сервере, так же как на запрос GET /index.php HTTP/1.1 не обязан возвращать вам страницу index.php, он может ее удалять, например 🙂
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.

REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).

REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).

В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.

Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.

HTTP: подробно о протоколе

HyperText Transfer Protocol (HTTP) — это протокол высокого уровня (а именно, уровня приложений), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.

Практические информационные системы требуют большего, чем примитивный поиск, модификация и аннотация данных. HTTP/1.0 предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier — URI), в виде местонахождения (URL) или имени (URN). Формат сообщений сходен с форматом Internet Mail или Multipurpose Internet Mail Extensions (MIME-Многоцелевое Расширение Почты Internet).

HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмотрщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, таким как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой-либо потери передавать данные с помощью упомянутых протоколов более ранних версий.

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

В Internet коммуникации обычно основываются на TCP/IP протоколах. Для WWW номер порта по умолчанию — TCP 80, но также могут быть использованы и другие номера портов — это не исключает возможности использовать HTTP в качестве протокола верхнего уровня.

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

Запрос — это сообщение, посылаемое клиентом серверу.
Первая строка этого сообщения включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса и используемую версию протокола. Для совместимости с протоколом HTTP/0.9, существует два формата HTTP запроса:

Запрос = Простой-Запрос | Полный-Запрос
 Простой-Запрос = "GET" SP Запрашиваемый-URI CRLF
 Полный-Запрос = Строка-Статус
                *(Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания ) CRLF
                [ Содержание-Запроса ]

Если HTTP/1.0 сервер получает Простой-Запрос, он должен отвечать Простым-Ответом HTTP/0.9. HTTP/1.0 клиент, способный обрабатывать Полный-Ответ, никогда не должен посылать Простой-Запрос.

Строка Статус начинается со строки с названием метода, за которым следует URI-Запроса и использующаяся версия протокола. Строка Статус заканчивается символами CRLF. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и CR, за исключением заключающей последовательности CRLF.

Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF

Следует отметить, что отличие Строки Статус Полного-Запроса от Строки Статус Простого- Запроса заключается в присутствии поля Версия-HTTP.

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

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" 
| дополнительный-метод

Список методов, допускаемых отдельным ресурсом, может быть указан в поле Заголовок-Содержание «Баллов». Тем не менее, клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса, так как допустимость применения различных методов может динамически изменяться. Если данный метод известен серверу, но не допускается для указанного ресурса, сервер должен вернуть код статуса «405 Method Not Allowed», и код статуса «501 Not Implemented», если метод не известен или не поддерживается данным сервером. Общие методы HTTP/1.0 описываются ниже.

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

Метод GET изменяется на «условный GET», если сообщение запроса включает в себя поле заголовка «If-Modified-Since». В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этого включает в себя следующие случаи:

  • Если код статуса ответа на запрос будет отличаться от «200 OK», или дата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будет идентичен ответу на обычный запрос GET.
  • Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.
  • Если ресурс не изменялся после указанной даты, сервер вернет код статуса «304 Not Modified».

Использование метода условный GET направлено на разгрузку сети, так как он позволяет не передавать по сети избыточную информацию.

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело- Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса. Метод «Условный HEAD», аналогичный условному GET, не определен.

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

  • Аннотация существующих ресурсов
  • Добавление сообщений в группы новостей, почтовые списки или подобные группы статей
  • Доставка блоков данных процессам, обрабатывающим данные
  • Расширение баз данных через операцию добавления

Реальная функция, выполняемая методом POST, определяется сервером и обычно зависит от URI- Запроса. Добавляемая информация рассматривается как субординатная указанному URI в том же смысле, как файл субординатен каталогу, в котором он находится, новая статья субординатна группе новостей, в которую она добавляется, запись субординатна базе данных.

Клиент может предложить URI для идентификации нового ресурса, включив в запрос заголовок «URI». Тем не менее, сервер должен рассматривать этот URI только как совет и может сохранить тело запроса под другим URI или вообще без него.

Если в результате обработки запроса POST был создан новый ресурс, ответ должен иметь код статуса, равный «201 Created», и содержать URI нового ресурса.

Метод PUT запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса «201 Created». Если существующий ресурс был модифицирован, должен быть послан ответ «200 OK», для информирования клиента об успешном завершении операции. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в Содержание-Запроса. Использующий запрос PUT точно знает какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

Метод DELETE используется для удаления ресурсов, идентифицированных с помощью URI-Запроса. Результаты работы данного метода на сервере могут быть изменены с помощью человеческого вмешательства (или каким-нибудь другим способом). В принципе, клиент никогда не может быть уверен, что операция удаления была выполнена, даже если код статуса, переданный сервером, информирует об успешном выполнении действия. Тем не менее, сервер не должен информировать об успехе до тех пор, пока на момент ответа он не будет собираться стереть данный ресурс или переместить его в некоторую недостижимую область.

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе Тело-Запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.

Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок «Link». Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Поля Заголовок-Запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Заголовок-Запроса = Accept | Accept-Charset | Accept-Encoding | 
                     Accept-Language | Authorization | From | 
                     If-Modified-Since | 
                     Pragma | Referer | User-Agent | extension-header

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

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

В случае присутствия поля From, оно должно содержать полный E-mail адрес пользователя, который управляет программой-агентом, осуществляющей запросы. Этот адрес должен быть задан в формате, определенном в RFC 822. Формат данного поля следующий: From = «From» «:» спецификация адреса. Например:

Данное поле может быть использовано для функций захода в систему, а также для идентификации источника некорректных или нежелательных запросов. Оно не должно использоваться, как несекретная форма разграничения прав доступа. Интерпретация этого поля состоит в том, что обрабатываемый запрос производится от имени данного пользователя, который принимает ответственность за применяемый метод. В частности, агенты-роботы должны использовать этот заголовок для того, чтобы можно было связаться с тем человеком, который отвечает за работу робота, в случае возникновения проблем. Почтовый Internet адрес, указывающийся в этом поле, не обязан соответствовать адресу того хоста, с которого был послан данный запрос. По возможности, адрес должен быть доступным Internet адресом вне зависимости от того, является ли он в действительности Internet E-mail адресом или Internet E-mail представлением адреса других почтовых систем.

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

Поле заголовка If-Modified-Since используется с методом GET для того, чтобы сделать его условным: если запрашиваемый ресурс не изменялся во времени, указанного в этом поле, копия этого ресурса не будет возвращена сервером; вместо этого, будет возвращен ответ «304 Not Modified» без Тела- Ответа.

If-Modified-Since = "If-Modified-Since" ":" HTTP-дата

Пример использования заголовка:

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

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

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

User-Agent = "User-Agent" ":" 1*( продукт ) 
 продукт = строка ["/" версия-продукта]
 версия-продукта = строка

Пример:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

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

После получения и интерпретации запроса, сервер посылает ответ в соответствии со следующей формой:

Ответ = Простой-Ответ | Полный-Ответ
 Простой-Ответ = [ Содержание-Ответа ]
 Полный-Ответ = Строка-Статус
                *( Общий-Заголовок | Заголовок-Ответа | Заголовок-Содержания) CRLF
                [ Содержание-Ответа ]

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

Первая строка Полного-Запроса является Строкой-Статус, состоящей из версии протокола, за которой следует цифровой код статуса и ассоциированное с ним текстовое предложение. Все элементы Строки-Статус разделены пробелами. Не разрешены символы CR и LF, за исключением завершающей последовательности CRLF.

Строка-Статус=Версия-HTTP SP Статус-Код SP Фраза-Об'яснение.

Так как Строка-Статус всегда начинается с версии протокола «HTTP/» 1*ЦИФРА «.» 1*ЦИФРА (например HTTP/1.0), существование этого выражения рассматривается как основное для определения того, является ли ответ Простым-Ответом, или Полным-Ответом. Хотя формат Простого-Ответа не исключает появления подобной строки (что привело бы к неправильной интерпретации сообщения ответа и принятию его за Полный-Ответ), вероятность такого появления близка к нулю.

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

Первая цифра Статус-Кода предназначена для определения класса ответа. Последние две цифры не выполняют никакой категоризирующей роли. Существует 5 значений для первой цифры:

  1. 1xx: Информационный — Не используется, но зарезервирован для использования в будущем
  2. 2xх: Успех — Запрос был полностью получен, понят, и принят к обработке.
  3. 3xx: Перенаправление — Клиенту следует предпринять дальнейшие действия для успешного выполнения запроса. Необходимое дополнительное действие иногда может быть выполнено клиентом без взаимодействия с пользователем, но настоятельно рекомендуется, чтобы это имело место только в тех случаях, когда метод, использующийся в запросе безразличен (GET или HEAD).
  4. 4xx: Ошибка клиента — Запрос, содержащий неправильные синтаксические конструкции, не может быть успешно выполнен. Класс 4xx предназначен для описания тех случаев, когда ошибка была допущена со стороны клиента. Если клиент еще не завершил запрос, когда он получил ответ с Статус-Кодом- 4xx, он должен немедленно прекратить передачу данных серверу. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.
  5. 5xx: Ошибка Сервера — Сервер не смог дать ответ на корректно поставленный запрос. В этих случаях
    сервер либо знает, что он допустил ошибку, либо не способен обработать запрос. За исключением ответов на запросы HEAD, сервер посылает описание ошибочной ситуации и то, является ли это состояние временным или постоянным, в Содержание-Ответа. Данный тип Статус-Кодов применим для любых методов, употребляющихся в запросе.

Отдельные значения Статус-Кодов и соответствующие им Фразы-Об’яснения приведены ниже. Данные Фразы-Об’яснения только рекомендуются — они могут быть замещены любыми другими фразами, сохраняющими смысл и допускающимися протоколом.

Статус-Код = "200" ; OK |
"201" ; Created |
"202" ; Accepted |
"203" ; Provisional Information |
"204" ; No Content |
"300" ; Multiple Choices |
"301" ; Moved Permanently |
"302" ; Moved Temporarily |
"303" ; Method |
"304" ; Not Modified |
"400" ; Bad Request |
"401" ; Unauthorized |
"402" ; Payment Required |
"403" ; Forbidden |
"404" ; Not Found |
"405" ; Method Not Allowed |
"406" ; None Acceptable |
"407" ; Proxy Authentication Required |
"408" ; Request Timeout |
"409" ; Conflict |
"410" ; Gone |
"500" ; Internal Server Error |
"501" ; Not Implemented |
"502" ; Bad Gateway |
"503" ; Service Unavailable |
"504" ; Gateway Timeout |
Код-Рассширения
Код-Расширения = 3ЦИФРА
Фраза-Об'яснение = строка *( SP строка )

От HTTP приложений не требуется понимание всех Статус-Кодов, хотя такое понимание, очевидно, желательно. Тем не менее, от приложений требуется способность распознавания классов Статус-Кодов (идентифицирующихся первой цифрой) и отношение ко всем Статус-Кодам статуса ответа, как если бы они были эквивалентны Статус-Коду x00.

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

Заголовок-Ответа= Public | Retry-After | Server | WWW-Authenticate | extension-header

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

Полный-Запрос и Полный-Ответ может использоваться для передачи некоторой информации в отдельных запросах и ответах. Этой информацией является Содержание-Запроса или Содержание-Ответа соответственно, а также Заголовок-Содержания.

Поля Заголовок-Содержания содержат необязательную метаинформацию о Содержании-Запроса или Содержании-Ответа соответственно. Если тело соответствующего сообщения (запроса или ответа) не присутствует, то Заголовок-Содержания содержит информацию о запрашиваемом ресурсе.

Заголовок-Содержания = Allow |
                        Content-Encoding | Content-Language | Content-Length |
                        Content-Transfer-Encoding | Content-Type |Derived-From |
                        Expires | Last-Modified |Link |
                        Location | Title | URI-header | Version | Заголовок-Расширения
 Заголовок-Расширения = HTTP-заголовок

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

Поле заголовка Allow представляет собой список методов, которые поддерживает ресурс, идентифицированный URI-Запроса. Назначение этого поля — точное информирование получателя о допустимых методах, ассоциированных с ресурсом; это поле должно присутствовать в ответе со статус кодом «405 Method Not Allowed».

Allow = "Allow" ":" 1#метод

Пример использования:

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

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

Content-Length = "Content-Length" ":" 1*ЦИФРА

Например:

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

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

Content-Type = "Content-Type" ":" тип-среды

Типы сред определены отдельно.
Пример:

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

Поле Content-Type не имеет значения по умолчанию.

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

Last-Modified = "Last-Modified" ":" HTTP-дата

Пример использования:

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

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

Под телом сообщения понимается Содержание-Запроса или Содержание-Ответа соответственно. Тело сообщения, если оно присутствует, посылается в HTTP/1.0 запросе или ответе в формате и кодировке, определяемыми полями Заголовок-Содержания.

Тело-Сообщения = *OCTET (где OCTET это любой 8-битный символ)

Тело сообщения включается в запрос, только если метод запроса подразумевает его наличие. Для спецификации HTTP/1.0 такими методами являются POST и PUT. В общем, на присутствие тела сообщения указывает присутствие таких полей заголовка содержания, как Content-Length и/или Content- Transfer-Encoding, в передаваемом запросе.

Что касается сообщений-ответов, наличие тела сообщения в ответе зависит от метода, который был использован в запросе, и Статус-Кода. Все ответы на запросы HEAD не должны содержать тело сообщения, хотя наличие некоторых полей заголовка сообщения может указывать на возможное присутствие такового. Соответственно, ответы «204 No Content», «304 Not Modified», и «406 None Acceptable» также не должны включать в себя тело сообщения.

телеграм канал. Подпишись, будет полезно!

HTTP Методы | Schoolsw3.com



Два наиболее часто используемых метода HTTP: GET и POST.


Что такое HTTP?

Протокол передачи гипертекста (HTTP) предназначен для обеспечения связи между клиентами и серверами.

HTTP работает как протокол запрос-ответ между клиентом и сервером.

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

Пример: Клиент (браузер) отправляет запрос HTTP на сервер; затем сервер возвращает ответ клиенту. Ответ содержит информацию о состоянии запроса, также может содержать запрошенное содержимое.


Два метода запроса HTTP: GET и POST

Два часто используемых метода для запроса-ответа между клиентом и сервером: GET и POST.

  • GET — Запрашивает данные из указанного ресурса
  • POST — Отправляет данные для обработки указанному ресурсу

Метод GET

Обратите внимание, что строка запроса (пары name/value) отправляется в URL запроса GET:

/test/demo_form.php?name1=value1&name2=value2

Некоторые другие примечания по запросам GET:

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

Метод POST

Обратите внимание, что строка запроса (пары name/value) отправляется в теле сообщения HTTP запроса POST:

POST /test/demo_form.php HTTP/1.1
Host: schoolsw3.com
name1=value1&name2=value2

Некоторые другие заметки о почтовых запросах:

  • POST запросы не кэшируются
  • POST запросы не остаются в истории браузера
  • POST запросы не могут быть помечены закладками
  • POST запросы не имеют ограничений по длине данных

Сравнение GET и POST

В следующей таблице сравниваются два метода HTTP: GET и POST.

  GET POST
Возврат Кнопка/Перезагрузка Безвредный Данные будут повторно отправлены (браузер должен предупредить пользователя о том, что данные будут повторно отправлены)
Закладка Могут быть закладки Не могут быть закладки
Кэширование Может быть кэширован Не кэшировать
Тип кодировки application/x-www-form-urlencoded application/x-www-form-urlencoded или multipart/form-data. Использовать кодировку для двоичных данных
История Параметры остаются в истории браузера Параметры не сохраняются в истории браузера
Ограничения на длину данных Да, при отправке данных метод GET добавляет данные в URL; длина URL адреса ограничена (Максимальная длина URL составляет 2048 символов) Не ограничивать
Ограничения типа данных Только символы ASCII Не ограничивать. Двоичные данные также разрешены
Безопасность GET менее безопасен по сравнению с POST, поскольку отправляемые данные являются частью URL

Никогда не используйте GET при отправке паролей или другой конфиденциальной информации!

POST немного безопаснее, чем GET, потому что параметры не хранятся в истории браузера или в журналах веб сервера
Видимость Данные видны всем в URL Данные не отображаются в URL

Другие методы запроса HTTP

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

Метод Описание
HEAD То же, что и GET, но возвращает только заголовки HTTP, а не тело документа
PUT Загружает представление указанного URI
DELETE Удаляет указанный ресурс
OPTIONS Возвращает методы HTTP, поддерживаемые сервером
CONNECT Преобразует соединение запроса в прозрачный туннель TCP/IP

Схема функционирования HTTP-сообщений и возможные риски

Схема функционирования HTTP-сообщений и возможные риски

В этой статье мы рассмотрим структуру HTTP-сообщений и проанализируем, что происходит за кадром при просмотре веб-страниц.

Автор: Ryan Brown

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

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

HTTP-запросы

Простой HTTP-запрос:

Рисунок 1: Элементарный HTTP-запрос

GET – HTTP-метод

/ — Путь к ресурсу

HTTP/1.1 – Версия протокола HTTP

HTTP-методы:

Протокол HTTP поддерживает несколько методов. В самой первой версии HTTP/1.0 было три метода: GET, POST и HEAD. В HTTP/1.1 появилось несколько новых методов (см. RFC 2616): OPTIONS, CONNECT, TRACE, PUT и DELETE. В RFC 5789, появившегося в 2010 году, добавился метод PATCH.

Рисунок 2: Перечень методов, поддерживаемых протоколом HTTP/1.1

GET используется для простого запроса ресурсов с веб-сервера. Параметры для этого метода передаются через URL.

POST используется для отсылки данных на веб-сервер через тело HTTP-запроса.

HEAD схож с методом GET, но выводит только заголовки HTTP-ответа, который возвращает сервер.

OPTIONS используется для получения списка методов, принимаемых веб-сервером, которые хранятся в заголовке ‘Allow’ в HTTP-ответе.

PUT предназначен для замены существующего или создания нового ресурса на веб-сервере.

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

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

PATCH схож с методом PUT. Отличие заключается в этом, что PATCH поддерживает частичную модификацию, в то время как метод PUT поддерживает только полную замену ресурса.

Примечание:

В большинстве приложений используются в основном GET и POST, поскольку HTML поддерживает только эти два метода. Если предполагается использование методов OPTIONS, PUT, DELETE, PATCH, TRACE или CONNECT, необходимо все тщательно продумать и оценить риски в отношении приложения или веб-сервера.

URL:

URL или Uniform Resource Locator (унифицированный указатель ресурсов) является подмножеством унифицированных идентификаторов ресурсов (Uniform Resource Identifiers; URI). Типичная структура URL выглядит так:

[Protocol]://[host]/[resource path]?[parameter1]&[parameter2]

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

Рисунок 3: Переменная HOST представляет собой сетевой адрес веб-сервера, куда клиент отсылает HTTP-запрос

Рисунок 4: Наиболее распространенные заголовки HTTP-запроса

User-Agent содержит информацию о браузере.

Accept определяет тип содержимого, который может принять клиент.

Accept-Encoding определяет тип кодировки, которую может принять клиент.

Content-Length определяет длину тела запроса в октетах. Это значение не имеет особой важности, но некоторые HTTP-методы (например, PUT) требуют этот заголовок. Если необходимо, в значение этого заголовка можно установить 0.

Referer содержит URL-источник запроса.

Cookie предназначен для отправки cookies на сервер для управления сессией.

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

Authorization содержит информацию, имеющую отношение к аутентификации на конкретной платформе. 

HTTP-ответы

Пример простого HTTP-ответа:

Рисунок 5: Элементарный HTTP-ответ

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

Рисунок 6: Перечень кодов статуса

Код ответа «100 Continue» редко когда-либо используется. Наиболее распространенный код «200 OK», который сигнализирует о том, что запрос корректен, ресурс существует, сервер обработал запрос и вернул ресурс в теле ответа. Код 201 означает, что ресурс, запрашиваемый в запросе, был успешно создан. Этот код обычно является результатом запроса с использованием метода PUT. Коды статуса 3xx возвращается приложениями со ссылкой на ресурс, куда нужно перенаправить клиента. Ссылка находится либо в тебе ответа, либо в заголовке «location». Коды статуса 4xx отсылаются в случае, если запрашиваемого ресурса на сервере не существует или пользователь не авторизован для получения содержимого или при возникновении ошибки в запросе, отправленном серверу. Коды статуса 5xx возвращаются в случае, когда сервере возникает ошибка, и нет возможности обработать запрос.

   
Рисунок 7: Наиболее распространенные HTTP-заголовки ответов

Date содержит дату, когда получен запрос.

Server содержит информацию о веб-сервере (например, IIS/Apache).

X-Powered-By содержит информацию, касающуюся технологии, используемой в скриптах, и текущую версию (например, PHP или Asp.net).

Content-Length схож с аналогичным заголовком в запросе. Содержит длину тела ответа в октетах.

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

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

Cache-Control указывает клиенту, нужно ли кэшировать возвращаемые запросы.

Пример HTTP-запроса с использованием метода GET:

Рисунок 8: Пример использования метода GET

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

Пример ответа на запрос с использованием метода GET:

Рисунок 9: Ответ на запрос с использованием метода GET

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

Пример использования метода POST:

Рисунок 10: Пример отправки информации методом POST

HTTP-запрос с использованием метода POST во многом схож с запросом с методом GET, который мы только что рассматривали. Основное отличие заключается в том, что параметры передаются не через URL, а через тело запроса. Этот метод более безопасен и пригоден для передачи конфиденциальной информации, поскольку передаваемые сведения нельзя получить из кэша на стороне клиента. Если планируется передавать параметры, имеющие отношение к аутентификации, следует использовать протокол HTTPS вместе с TLS с целью включения функции шифрования передаваемой информации. Заголовок Content-Length содержит длину тела запроса в октетах. И, наконец, заголовок Referer указывает серверу место возникновения запроса.

Пример HTTP-запроса с методом TRACE:

Рисунок 11: Запрос с использованием метода TRACE

Пример ответа на запрос с методом TRACE:

Рисунок 12: Ответ на запрос с методом TRACE

Как видно из рисунка выше, при использовании метода TRACE сервер возвращает в теле ответа все, что было отправлено в запросе. Эта функция может быть полезна в том случае, если клиенту нужно точно знать, что получено сервером. Метод TRACK выполняет ту же самую функцию, но используется при работе с сервером Microsoft IIS. Уязвимости, которые могут возникать при использовании метода TRACE, связаны с межсайтовой трассировкой (Cross-Site Tracing; XST). Этот класс брешей злоумышленник может использовать для кражи cookie или другой конфиденциальной информации (например, учетных записей), хранимых в заголовке Authorization при помощи межсайтового скриптинга (XSS).

Пример HTTP-запроса с методом PUT:

Рисунок 13: Создание простейшей страницы при помощи метода PUT

Метод PUT требует использования в запросе заголовка Content-Length. Значение этого заголовка особого значение не имеет и может быть установлено нулевым без каких-либо непредсказуемых последствий. Если директория, указанная в URL, уже существует на сервере, соответствующий ресурс будет полностью заменен. Если ресурса, указанного в URL, не существует, то будет создан новый ресурс (предполагается, что соответствующий метод реализован на сервере). Содержимое ресурса, который нужно создать, указывается в теле запроса. В примере выше создается простая html-страница.

Пример ответа на запрос с методом PUT:

Рисунок 14: Ответ с кодом об успешном создании страницы

В идеале от сервера должен прийти ответ с кодом статуса «201 Created», свидетельствующий о том, что ресурс создан. Кроме того, в HTTP-запрос можно было бы вставить заголовок «Expect: 100-continue», чтобы удостовериться, что сервер готов к обработке и не закроет сокет до того, как получит содержимое, которое вы указали в теле запроса. При использовании в запросе заголовка «Expect» в ответ может прийти один из двух кодов статуса: «100 Continue» или «417 Expectation Failed».

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

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

Пример HTTP-запроса с методом PUT и вставкой кода шелла:

Рисунок 15: Пример использования кода шелла в теле запроса

Пример HTTP-запроса с методом DELETE:

Рисунок 15: Запрос на удаление ресурса при помощи метода DELETE

Пример ответа на запрос с методом DELETE:

Рисунок 16: Ответ на запрос об успешном удалении ресурса

После успешного удаления ресурса, указанного в URL, сервер должен вернуть код статуса 200 OK.

Пример HTTP-запроса с методом OPTIONS:

Рисунок 17: Запрос методов, доступных на сервере, при помощи метода OPTIONS

Пример ответа на запрос с методом OPTIONS:

Рисунок 18: Ответ с перечнем методов, доступных на сервере

Цель метода OPTIONS – узнать, какие методы разрешены на сервере. При помощи этого метода нельзя нанести какой-либо ущерб, а только собрать нужную информацию. Важно отметить, что содержимое заголовка «Allow» в заголовке ответа часто содержит методы, разрешенные не на сервере, а на прокси-сервере в случае, если трафик проходит через туннель.

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

15 тривиальных фактов о правильной работе с протоколом HTTP / Яндекс corporate blog / Habr

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.

Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.


1. URL идентифицирует ресурс — некоторую разделяемую сущность. Файл — ресурс. Ручка, которая что-то ищет — ресурс. Вызов метода — не ресурс. Если вы хотите шарахнуть из пушки по Луне, то вот так делать не надо:

GET /?method=шарахнуть&to=Луна

Заведите ресурс «шарахалка», и тогда у вас всё будет логично:

POST /шарахалка/?to=Луна

Почему POST, а не GET? Читай ниже.

2. URL состоит из схемы (протокола), хоста, пути (path), запроса (query) и фрагмента. Путь используется для организации иерархических ресурсов, запрос — для неиерархических ресурсов и для параметров операции. Фрагмент идентифицирует подчинённый ресурс, не имеющий прямого URL.

Scheme      Host                 Path               Query      Fragment
  ↓           ↓                    ↓                  ↓            ↓
http://nyashnye-kotiki.xxx/breeds/maine-coon/?deliver_to=Moscow#photo

Если на вашем сайте «Няшные котики» есть каталог по породам, то его вполне логично организовать в виде частей path, поскольку каждый котик принадлежит ровно к одной породе. А вот доставлять одного котика можно в несколько городов, поэтому фильтр «с доставкой в город N» следует организовать через query.

3. Обращение по HTTP состоит из применения метода (глагола) к URL. Результатом такого применения должно быть — сюрприз-сюрприз! — то, что в глаголе написано. То есть GET возвращает представление ресурса, DELETE удаляет и т.п.

4. Методы GET, HEAD, OPTIONS — безопасные. Предполагается, что вызов этих методов состояния ресурса не изменяет. Поэтому многие сетевые агенты — такие, например, как префетчер ссылок в браузере или мессенджере — считают себя вправе по таким ссылкам ходить без явного волеизъявления пользователя. ИЧСХ, никаких стандартов не нарушают.

5. По умолчанию методы GET и HEAD кэшируются, OPTIONS, POST, PUT, PATCH, DELETE — нет. Поэтому если вы шарахнули по Луне методом POST, вы можете быть (почти) уверены, что этот запрос выполнится. Если вы шарахаете методом GET, какой-нибудь промежуточный прокси может ВНЕЗАПНО отдать вам ответ из кэша, и шарах в реальности не произойдёт.

6. Операции GET, PUT, DELETE симметричны. PUT кладёт нечто по URL-у (создавая новый ресурс или перезаписывая старый), GET по этому URL-у возвращает представление того, что положил PUT, DELETE удаляет ресурс.

Метод HEAD синонимичен по семантике методу GET, но не возвращает тело ответа, а только его заголовки (метаинформацию о ресурсе).

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

PUT /threads/php-rulezz/messages/100500

Если клиенту генерировать id не разрешено, ему придётся делать POST на ресурс уровнем выше по иерархии:

POST /threads/php-rulezz/messages

И этот ресурс сам создаст новое сообщение.
Обратите внимание, если вы по ошибке или вследствие сетевых проблем повторите POST запрос — создастся второе сообщение в треде, идентичное первому. PUT вы можете делать хоть 100500 раз, результат не изменится. Это свойство называется идемпотентностью.
Ладно создание постов на форуме. Вот если вы делаете тяжёлую и дорогую операцию по пользовательскому запросу — очень рекомендуется выполнять для этого идемпотентный запрос. А то может получиться как на картинке:

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

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

9. Коды ответа нужны в первую очередь для того, чтобы клиент мог понять, что ему делать дальше. 3хх говорит, что для успешного выполнения запроса нужно выполнить дополнительное действие. 4хх говорит, что клиент, составляя запрос, сделал что-то неправильно и, обычно, о том, что умолять бесполезно — повторное выполнение запроса всё равно выкинет ошибку. В 4хх крайне рекомендуется включать информацию о том, что конкретно клиент сделал не так. 5хх говорит о том, что клиент всё сделал правильно — проблема на стороне сервера.

Обычно при успешном выполнении операции сервер отвечает на GET — 200, на PUT — 201 Created (если ресурс создан) или 200 (ресурс обновлён), на DELETE — 204 (операция успешна, возвращать нечего), на POST — 200 или 201 (во втором случае в заголовке, обычно Location, указывается URL созданного ресурса).

10. Работая с HTTP-статусами, не наступите на популярные грабли:

  • статус 401 Unauthorized обязан сопровождаться заголовком WWW-Authenticate и, таким образом, применим только тогда, когда клиент аутентифицируется посредством HTTP-аутентификации; во всех остальных случаях следует использовать 403 Forbidden;
  • статусы 3xx — это не только редиректы; они показывают, что клиент должен выполнить дополнительное действие, иначе запрос не может считаться успешным; например, по статусу 304 Not Modified клиент должен взять актуальную версию ресурса из кэша;
  • статус 404, как ни странно, один из немногих 4xx статусов, которые клиент имеет право повторять — он означает, что ресурса сейчас нет, но вполне возможно, что он появится; вообще 404 — статус неопределённости, который используется, если сервер не хочет раскрывать механику ошибки; для того, чтобы индицировать клиенту, что без дополнительных действий с его стороны ресурс не появится, следует использовать 410 Gone (ресурс был удалён) либо общий статус 400.

11. Существует особый подкласс URL-ов, которые кодируют в себе и ресурс, и действие над ним. В англоязычной литературе их принято называть Capability URLs. Классический пример такого URL — ссылки на восстановление паролей, а также всевозможные «секретные» прямые ссылки на всяческие ресурсы.

12. Поскольку основная опасность при работе с Capability URL — возможность их утечки, следует максимально закрыть возможности случайно такой URL найти или перехватить:

  • для генерации секретных частей URL должен использоваться сильный генератор случайных строк (например, UUID 4), исключающий возможности найти Capability URL перебором; разумеется, URL не должен генерироваться детерминированным способом типа md5(username) и такие URL нельзя пропускать через сокращатели ссылок;
  • Capability URLs должны работать только по HTTPS;
  • страницы, доступные через Capability URL, должны быть закрыты wildcard-ом от индексации роботами.

13. Должны быть предусмотрены меры минимизации возможного ущерба:

пользователь, создавший Capability URL (например, расшаривший документ), должен иметь возможность сделать обратную операцию, т.е. отозвать URL;

Capability URLs должны протухать со временем; чем опаснее предоставляемый доступ, тем короче должен быть срок жизни URL.

14. Наконец, сами «секретные» страницы должны быть защищены от сливания данных сторонним агентам:

  • на них не должно быть никаких third-party скриптов и картинок, желательно — на уровне CSP;
  • на них не должно быть ссылок на third-party сайты; если они необходимы, то нужно скрывать referrer, например, через rel=«noreferrer»;
  • вообще желательно через Referrer Policy настроить скрытие referrer-а;
  • желательно сразу после захода пользователя через History API менять URL в адресной строке браузера, чтобы его нельзя было подсмотреть через плечо;
  • если ссылка предполагает какое-то действие (например, смену пароля), то на секретной странице должна быть форма (кнопка, скрипт), которую требуется отослать, чтобы действие осуществить, причём эта форма должно быть подписана CSRF-токеном (иначе префетчер браузера / почтового клиента / мессенджера сможет восстановить пароль за юзера).

15. Всё описанное выше существует в стандартах исключительно в форме рекомендации, и принудить кого-либо к строгому исполнению этих рекомендаций нельзя. Я уже не первый раз рассказываю про всю эту тривию, и часто слышу в ответ «да плевать я на всё это хотел, придумали какой-то ненужной ерунды; как у меня работали все сервисы только на GET, так и дальше будут, мучайтесь со своими PUT-ами и DELETE-ми сами».

Разумеется, вы вольны писать свой сервис сами. Но имейте, пожалуйста, в виду, что между вашим сервером и вашим клиентом, даже если они стоят физически рядышком в одном ДЦ, есть огромное множество других сетевых агентов — браузеров, прокси, роутеров, имплементаций HTTP-протокола в разных языках программирования и разных ОС, DPI-оборудование провайдеров и так далее. Все эти агенты плюс-минус имплементируют протокол HTTP с оглядкой на RFC.

Если вдруг клиентский браузер запрефетчит GET-ссылку и шарахнет по Луне — это будет ваша вина, бесполезно писать производителю. Если у вас деньги переводятся GET-запросом, а имплементация HTTP протокола в вашем языке программирования, не дождавшись ответа от соседнего роутера, решит повторить запрос и проведёт транзакцию дважды — это будет опять ваша вина.

Но даже не это главное. Допустим, ваши HTTP-пакеты гуляют в строго контролируемой среде. Как вы собираетесь объяснять другим разработчикам, какие рекомендации вы нарушили и почему? Как ваш коллега должен понять, что вот этот GET-запрос повторять нельзя, а статус 400 вовсе не означает клиентскую ошибку? Отступая от рекомендаций, вы, фактически, каждый раз создаёте какой-то свой диалект HTTP с собственной семантикой. Не забудьте его хотя бы задокументировать 😉

Список литературы:

(В разработке последнего документа ваш покорный слуга принимал определённое участие.)

HTTP-методов GET против POST


Что такое HTTP?

Протокол передачи гипертекста (HTTP) предназначен для
связь между клиентами и серверами.

HTTP работает как протокол запроса-ответа между клиентом и сервером.

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


Методы HTTP

  • ПОЛУЧИТЬ
  • ПОСТ
  • УСТАНОВИТЬ
  • ГОЛОВКА
  • УДАЛИТЬ
  • НАШИВКА
  • ОПЦИИ

Два наиболее распространенных метода HTTP: GET и POST.


Метод GET

GET используется для запроса данных от указанного
ресурс.

GET — один из наиболее распространенных методов HTTP.

Обратите внимание, что строка запроса (пары имя / значение) отправляется в URL-адресе
запрос GET:

/test/demo_form.php?name1=value1&name2=value2

Некоторые другие примечания по запросам GET:

  • GET-запросы можно кэшировать
  • запросов GET остаются в истории браузера
  • GET запросов можно добавить в закладки
  • Запросы

  • GET никогда не должны использоваться при работе с конфиденциальными данными
  • GET-запросы имеют ограничения по длине
  • GET-запросы используются только для запроса данных (не для изменения)

Метод POST

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

Данные, отправленные на сервер с помощью POST, хранятся в теле запроса
HTTP-запрос:

POST /test/demo_form.php HTTP / 1.1
Хост: w3schools.com
имя1 = значение1 и имя2 = значение2

POST — один из наиболее распространенных методов HTTP.

Некоторые другие примечания к запросам POST:

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


Метод PUT

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

Разница между POST и PUT в том, что запросы PUT идемпотентны. Который
то есть вызов одного и того же запроса PUT несколько раз всегда будет приводить к одному
результат. Напротив, многократный вызов POST-запроса имеет побочные эффекты:
создание одного и того же ресурса несколько раз.


Метод HEAD

HEAD практически идентичен GET, но без тела ответа.

Другими словами, если GET / users возвращает список пользователей, то HEAD / users будут
сделать тот же запрос, но не вернет список пользователей.

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


Метод DELETE

Метод DELETE удаляет указанный ресурс.


Метод OPTIONS

Метод OPTIONS описывает параметры связи для целевой
ресурс.


Сравнить GET с POST

В следующей таблице сравниваются два метода HTTP: GET и POST.

ПОЛУЧИТЬ ПОСТ
Кнопка НАЗАД / перезагрузка Безвредный Данные будут отправлены повторно (браузер должен предупредить пользователя о том, что данные будут отправлены повторно)
Помещено в закладки Можно добавить в закладки Невозможно добавить в закладки
Кэширование Можно кэшировать Не кэшируется
Тип кодирования приложение / x-www-form-urlencoded application / x-www-form-urlencoded или multipart / form-data.Использовать многостраничное кодирование для двоичных данных
История Параметры остаются в истории браузера Параметры не сохраняются в истории браузера
Ограничения на длину данных Да, при отправке данных метод GET добавляет данные в URL; и длина URL-адреса ограничена (максимальная длина URL-адреса составляет 2048 символов) Без ограничений
Ограничения на тип данных Разрешены только символы ASCII Без ограничений.Допускаются также двоичные данные
Безопасность GET менее безопасен по сравнению с POST, потому что отправленные данные являются частью URL-адреса

Никогда не используйте GET при отправке паролей или другой конфиденциальной информации!

POST немного безопаснее, чем GET, поскольку параметры не хранятся в истории браузера или в журналах веб-сервера
Видимость Данные видны всем в URL Данные не отображаются в URL-адресе

.

HTTP / 1.1: определения методов

HTTP / 1.1: определения методов

часть протокола передачи гипертекста — HTTP / 1.1
RFC 2616 Fielding, et al.

9 Определения методов

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

Поле заголовка запроса хоста (раздел 14.23) ДОЛЖНО сопровождать все
HTTP / 1.1 просьба.

9.1 Безопасные и идемпотентные методы

9.1.1 Безопасные методы

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

В частности, было установлено, что GET и
Методы HEAD НЕ ДОЛЖНЫ иметь значение выполнения действия
кроме поиска.Эти методы следует считать «безопасными».
Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT.
и DELETE особым образом, чтобы пользователь знал о
тот факт, что запрашивается возможно небезопасное действие.

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

9.1.2 Идемпотентные методы

Методы также могут обладать свойством «идемпотентности» в этом (помимо
из-за ошибки или истечения срока действия) побочные эффекты N> 0 идентичны
запросы такие же, как и для одиночного запроса. Методы GET, HEAD,
PUT и DELETE совместно используют это свойство. Также методы OPTIONS и
TRACE НЕ ДОЛЖЕН иметь побочных эффектов, и поэтому они по своей природе идемпотентны.

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

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

9.2 ОПЦИИ

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

Ответы на этот метод не кэшируются.

Если запрос OPTIONS включает тело объекта (как указано
наличие Content-Length или Transfer-Encoding), затем тип носителя
ДОЛЖЕН быть обозначен полем Content-Type. Хотя это
спецификация не определяет использование такого тела, будущее
расширения HTTP могут использовать тело OPTIONS, чтобы сделать более подробными
запросы на сервере. Сервер, который не поддерживает такой
extension МОЖЕТ отбросить тело запроса.

Если Request-URI — звездочка («*»), запрос OPTIONS
предназначен для применения к серверу в целом, а не к конкретному
ресурс.Поскольку параметры связи сервера обычно зависят от
ресурс, запрос «*» полезен только как «пинг» или «без операции»
тип метода; он ничего не делает, кроме того, что позволяет клиенту протестировать
возможности сервера. Например, это можно использовать для проверки
прокси на соответствие HTTP / 1.1 (или его отсутствие).

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

Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают
дополнительные функции, реализованные сервером и применимые к нему
ресурс (например, Allow), возможно, включая расширения, не определенные
эта спецификация. В текст ответа, если таковой имеется, СЛЕДУЕТ также включать
информация о вариантах связи. Формат такого

тело не определено в этой спецификации, но может быть определено
будущие расширения HTTP.Согласование содержимого МОЖЕТ использоваться для выбора
соответствующий формат ответа. Если тело ответа не включено,
ответ ДОЛЖЕН включать поле Content-Length со значением поля
«0».

Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для нацеливания на
конкретный прокси в цепочке запросов. Когда прокси получает OPTIONS
запрос на absoluteURI, для которого разрешена пересылка запроса,
прокси-сервер ДОЛЖЕН проверять поле Max-Forwards.Если Max-Forwards
значение поля равно нулю («0»), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение;
вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи.
Если значение поля Max-Forwards является целым числом больше нуля,
прокси ДОЛЖЕН уменьшать значение поля при пересылке запроса. Если
в запросе нет поля Max-Forwards, то перенаправленное
запрос НЕ ДОЛЖЕН включать поле Max-Forwards.

9,3 ПОЛУЧИТЬ

Метод GET означает получение любой информации (в виде
entity) идентифицируется Request-URI.Если Request-URI ссылается на
для процесса производства данных именно произведенные данные должны быть
возвращается как объект в ответе, а не как исходный текст
процесса, если только этот текст не является результатом процесса.

Семантика метода GET изменяется на «условный GET», если
сообщение запроса включает If-Modified-Since, If-Unmodified-Since,
Поле заголовка If-Match, If-None-Match или If-Range. Условный GET
метод требует, чтобы объект был передан только под
обстоятельства, описанные условным полем (ями) заголовка.В
условный метод GET предназначен для уменьшения ненужных сетевых
использование, позволяя обновлять кэшированные объекты без необходимости
множественные запросы или передача данных, уже имеющихся у клиента.

Семантика метода GET изменяется на «частичный GET», если
сообщение запроса включает поле заголовка диапазона. Частичные запросы GET
что только часть предприятия будет передана, как описано в разделе
14.35. Частичный метод GET предназначен для сокращения ненужных
использование сети, позволяя частично извлеченным объектам быть
завершено без передачи данных, уже имеющихся у клиента.

Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует
требования к HTTP-кешированию, описанные в разделе 13.

См. Раздел 15.1.3 для ознакомления с соображениями безопасности при использовании для форм.

ГОЛОВКА 9,4

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН
вернуть тело сообщения в ответ. Метаинформация содержала
в заголовках HTTP в ответ на запрос HEAD ДОЛЖНЫ быть идентичными
к информации, отправленной в ответ на запрос GET.Этот метод может
использоваться для получения метаинформации о сущности, подразумеваемой
запрос без передачи самого тела объекта. Этот метод
часто используется для проверки гипертекстовых ссылок на валидность, доступность,
и недавняя модификация.

Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что
информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления
ранее кэшированный объект из этого ресурса. Если новые значения поля
указывают, что кэшированный объект отличается от текущего объекта (как
будет обозначено изменением Content-Length, Content-MD5, ETag
или Last-Modified), то кеш ДОЛЖЕН обрабатывать запись кэша как
несвежий.

9,5 ПОСТ

Метод POST используется для запроса, чтобы исходный сервер принял
сущность, заключенная в запрос как новый подчиненный ресурс
идентифицируется Request-URI в строке запроса. POST разработан
чтобы унифицированный метод охватывал следующие функции:

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

Фактическая функция, выполняемая методом POST, определяется
server и обычно зависит от Request-URI. Размещенная сущность
подчиняется этому URI так же, как и файл
к каталогу, содержащему его, новостная статья подчиняется
группа новостей, в которой она размещена, или запись подчиняется
база данных.

Действие, выполняемое методом POST, может не привести к
ресурс, который можно идентифицировать по URI.В этом случае либо 200
(ОК) или 204 (Нет содержимого) — соответствующий статус ответа,
в зависимости от того, содержит ли ответ объект, который
описывает результат.

Если ресурс был создан на исходном сервере, ответ
ДОЛЖЕН быть 201 (Создано) и содержать объект, который описывает
статус запроса и относится к новому ресурсу, а Location
заголовок (см. раздел 14.30).

Ответы на этот метод не кэшируются, если только ответ
включает соответствующие поля заголовка Cache-Control или Expires.Однако,
ответ 303 (см. прочее) можно использовать для направления пользовательского агента на
получить кэшируемый ресурс.

Запросы POST ДОЛЖНЫ подчиняться изложенным требованиям передачи сообщений.
в разделе 8.2.

См. Раздел 15.1.3 по соображениям безопасности.

9,6 PUT

Метод PUT запрашивает, чтобы закрытый объект был сохранен в
предоставленный Request-URI. Если Request-URI ссылается на уже
существующий ресурс, закрытый объект СЛЕДУЕТ рассматривать как
модифицированная версия того, что находится на исходном сервере.Если
Request-URI не указывает на существующий ресурс, и этот URI
может быть определен как новый ресурс запрашивающим пользователем
агент, исходный сервер может создать ресурс с этим URI. Если
создается новый ресурс, исходный сервер ДОЛЖЕН проинформировать пользовательский агент
через ответ 201 (Создано). Если существующий ресурс изменен,
ДОЛЖНЫ быть отправлены коды ответа 200 (ОК) или 204 (Нет содержимого)
чтобы указать на успешное выполнение запроса.Если ресурс
не может быть создан или изменен с помощью Request-URI, подходящего
СЛЕДУЕТ дать ответ об ошибке, который отражает характер
проблема. Получатель объекта НЕ ДОЛЖЕН игнорировать любой Content- *
(например, Content-Range) заголовки, которые он не понимает или не реализует
и ДОЛЖЕН возвращать ответ 501 (Не реализовано) в таких случаях.

Если запрос проходит через кеш и Request-URI идентифицирует
один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть
рассматривается как устаревший.Ответы на этот метод не кэшируются.

Принципиальная разница между запросами POST и PUT заключается в следующем:
отражено в другом значении Request-URI. URI в
POST-запрос идентифицирует ресурс, который будет обрабатывать вложенные
организация. Этот ресурс может быть процессом приема данных, шлюзом к
какой-то другой протокол или отдельный объект, который принимает аннотации.
Напротив, URI в запросе PUT идентифицирует вложенный объект
с запросом — пользовательский агент знает, какой URI предназначен и
сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу.Если сервер желает, чтобы запрос был применен к другому URI,

он ДОЛЖЕН отправить ответ 301 (перемещен навсегда); пользовательский агент МОЖЕТ
затем принять собственное решение относительно того, перенаправлять или нет
запрос.

Один ресурс МОЖЕТ быть идентифицирован множеством разных URI. За
например, у статьи может быть URI для идентификации «текущего
версия «, который отличается от URI, определяющего каждый конкретный
версия.В этом случае запрос PUT для общего URI может привести к
несколько других URI, определяемых исходным сервером.

HTTP / 1.1 не определяет, как метод PUT влияет на состояние
исходный сервер.

Запросы PUT ДОЛЖНЫ подчиняться изложенным требованиям к передаче сообщений.
в разделе 8.2.

Если иное не указано для конкретного заголовка объекта,
заголовки объектов в запросе PUT ДОЛЖНЫ применяться к ресурсу
созданный или измененный PUT.

9.7 УДАЛИТЬ

Метод DELETE запрашивает у исходного сервера удаление ресурса.
идентифицированный Request-URI. Этот метод МОЖЕТ быть переопределен человеком.
вмешательство (или другие средства) на исходный сервер. Клиент не может
гарантировать, что операция была проведена, даже если
код состояния, возвращенный исходным сервером, указывает, что действие
был успешно завершен. Однако серверу НЕ СЛЕДУЕТ
указывает на успех, если в момент получения ответа
намеревается удалить ресурс или переместить его в недоступный
место расположения.

Успешный ответ ДОЛЖЕН быть 200 (OK), если ответ включает
сущность, описывающая статус, 202 (Принято), если действие не
еще не было выполнено, или 204 (Нет содержимого), если действие было выполнено
но ответ не включает сущность.

Если запрос проходит через кеш и Request-URI идентифицирует
один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть
рассматривается как устаревший. Ответы на этот метод не кэшируются.

9,8 СЛЕД

Метод TRACE используется для вызова удаленного цикла на уровне приложения.
обратная сторона сообщения запроса. Конечный получатель запроса
СЛЕДУЕТ отражать полученное сообщение обратно клиенту как
entity-body ответа 200 (OK). Конечным получателем является либо

исходный сервер или первый прокси или шлюз, который получит Max-Forwards
значение нуля (0) в запросе (см. раздел 14.31). Запрос TRACE
НЕ ДОЛЖЕН включать сущность.

TRACE позволяет клиенту видеть, что получает другой
конец цепочки запросов и использовать эти данные для тестирования или диагностики
Информация. Значение поля заголовка Via (раздел 14.45) равно
особый интерес, поскольку он действует как след цепочки запросов.
Использование поля заголовка Max-Forwards позволяет клиенту ограничивать
длина цепочки запросов, что полезно для тестирования цепочки
прокси пересылают сообщения в бесконечном цикле.

Если запрос действителен, ответ ДОЛЖЕН содержать все
сообщение запроса в теле объекта с типом содержимого
«сообщение / http». Ответы на этот метод НЕ ДОЛЖНЫ кэшироваться.

9.9 ПОДКЛЮЧИТЬ

В этой спецификации зарезервировано имя метода CONNECT для использования с
прокси, который может динамически переключаться на туннель (например, SSL
туннелирование [44]).

.

Учебное пособие по протоколу HTTP

Автор Xah Lee. Дата: . Последнее обновление: .

Через 10 минут вы получите базовое представление о протоколе HTTP.

Вот краткое описание протокола HTTP:

  • Модель клиент / сервер.
  • Запрос / ответ. Клиент делает запрос к серверу, сервер отвечает.
  • Запрос обычно отправляется через TCP через порт 80. [см. Руководство по TCP / IP для начинающих]
  • Формат запроса / ответа — это простой текст, состоящий из двух частей, заголовка и полезной нагрузки (содержимого), разделенных пустой строкой.
  • Первая строка сообщения запроса называется строкой запроса. Он содержит «команду».
  • Первая строка ответного сообщения называется строкой состояния. Он содержит «код состояния».
  • Существуют различные «команды», технически называемые «методами запроса». Наиболее полезны GET и POST. GET в основном просто запрашивает ресурс (например, файл или любые данные, идентифицированные путем). POST означает отправку некоторых данных на сервер, например, необходимых для входа в систему или диаграммы покупок.
  • Каждый ответ имеет код состояния.

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

  1. Браузер отправляет запрос на сервер. (Адрес сервера содержится в URL.)
  2. Сервер отправляет ответ, также простой текст. (если это файл изображения, изображение кодируется в текст.)
  3. Браузер отображает результат. (если это HTML, браузер анализирует его и может делать другие запросы, такие как изображения, таблица стилей, файл JavaScript и т. д.)

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

Как просмотреть сообщения HTTP

См. Заголовки HTTP в веб-браузере

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

Браузер Google Chrome показывает заголовки сообщений HTTP.

Вот как использовать Google Chrome для просмотра сообщений HTTP:

  1. Откройте инструмент веб-разработки. (В Google Chrome нажмите F12 в Windows или Linux. В других браузерах / ОС есть аналогичный инструмент.Вы можете найти это в их меню.)
  2. Щелкните вкладку Сеть.
  3. Посетите какую-либо страницу, введите URL-адрес в поле URL-адреса и нажмите Введите .
  4. Щелкните элемент в левой части сетевого отчета, чтобы просмотреть заголовок сообщения HTTP для этого элемента. (каждый элемент представляет собой HTTP-запрос, сделанный браузером.)
Команда Linux для просмотра заголовков HTTP

Следующие инструменты командной строки могут просматривать заголовок ответа HTTP.

  • curl - пример головы.com
  • wget --server-response --spider example.com

Вот пример curl:

curl --head example.com

HTTP / 1.1 200 ОК
Accept-Ranges: байты
Cache-Control: max-age = 604800
Тип содержимого: текст / html; charset = UTF-8
Дата: пн, 11 марта 2019 г., 04:25:57 GMT
Etag: "1541025663"
Истекает: Mon, 18 Mar 2019 04:25:57 GMT
Последнее изменение: пт, 9 августа 2013 г., 23:54:35 GMT
Сервер: ECS (sjc / 4E4E)
X-Cache: HIT
Длина содержимого: 1270
 

Вот пример wget:

wget --server-response --spider пример.com

Включен режим паука. Проверьте, существует ли удаленный файл.
--2019-03-10 21: 29: 03-- http://example.com/
Разрешение example.com (example.com) ... 2606: 2800: 220: 1: 248: 1893: 25c8: 1946, 93.184.216.34
Подключение к example.com (example.com) | 2606: 2800: 220: 1: 248: 1893: 25c8: 1946 |: 80 ... подключено.
HTTP-запрос отправлен, ожидает ответа ...
  HTTP / 1.1 200 ОК
  Кодирование содержимого: gzip
  Accept-Ranges: байты
  Cache-Control: max-age = 604800
  Тип содержимого: текст / html; charset = UTF-8
  Дата: пн, 11 марта 2019 г., 04:29:03 GMT
  Etag: "1541025663"
  Истекает: Mon, 18 Mar 2019 04:29:03 GMT
  Последнее изменение: пт, 9 августа 2013 г., 23:54:35 GMT
  Сервер: ECS (sjc / 4E45)
  X-Cache: HIT
  Длина содержимого: 606
Длина: 606 [text / html]
Удаленный файл существует и может содержать дополнительные ссылки,
но рекурсия отключена - не извлекается.

[см. Linux: веб-сайт загрузки: wget, curl]

Другие языки, такие как Python и Ruby, имеют аналогичные инструменты или библиотеки.

Обмен сообщениями клиент / сервер

Пример сообщения, отправленного клиентом:

 GET /hello.txt HTTP / 1.1
Пользовательский агент: curl / 7.16.3 libcurl / 7.16.3 OpenSSL / 0.9.7l zlib / 1.2.3
Хост: www.example.com
Принять-язык: en, mi 

Пример сообщения, отправленного сервером:

 HTTP / 1.1 200 ОК
Дата: понедельник, 27 июля 2009 г., 12:28:53 GMT
Сервер: Apache
Последнее изменение: среда, 22 июля 2009 г., 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: байты
Длина содержимого: 51
Vary: Accept-Encoding
Content-Type: текст / простой

Привет мир! Моя полезная нагрузка включает в себя завершающий CRLF.

Строки в сообщении HTTP должны быть разделены последовательностью символов "\ r \ n" .
(то есть возврат каретки с последующим переводом строки. Да, и то и другое.)
[см. таблицу ASCII]

Сообщение, которым обменивается клиент / сервер, представляет собой простой текст.
Он состоит из 2 частей: заголовка и содержимого.

Заголовок и содержимое разделяются 1 пустой строкой.

Первая строка заголовка особенная.

Если это запрос, он называется строкой запроса. Например, это выглядит так:

GET / tutorial / index.html HTTP / 1.1

Если это ответ, это называется строкой состояния. Например, это выглядит так:

HTTP / 1.1 200 ОК

Остальная часть заголовка состоит из строк, каждая строка называется « поле ».

Поле разделяется первым двоеточием : на две части: имя поля и значение поля.

HTTP-методы

Напомним, что первая строка запроса выглядит так: GET /tutorial/index.html HTTP / 1.1

Он состоит из 3 частей: ① метод запроса. ② путь к ресурсам. ③ http-версия.

Наиболее часто используемые методы запроса:

  • GET → запросить ресурс.
  • HEAD → То же, что и GET, но только заголовки, без содержимого. То есть просто запросите метаданные. Полезно для поискового робота, прокси-сервера и т. Д.
  • POST → Отправить некоторую информацию на сервер. Например, используется для входа в систему, кредитной карты, корзины покупок через HTML-форму. [см. пример HTML-формы]

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

Ниже приводится более полный список из HTTP / 1.1.
(источник — Википедия 11.03.2019)

  • GET → запрашивает представление указанного ресурса. Запросы с использованием GET должны только получать данные и не должны иметь никакого другого эффекта. (Это также верно и для некоторых других методов HTTP.) W3C опубликовал руководящие принципы по этому различию, в которых говорится: «Дизайн веб-приложения должен основываться на вышеуказанных принципах, но также и на соответствующих ограничениях». См. Безопасные методы ниже.
  • HEAD → запрашивает ответ, идентичный таковому для запроса GET, но без тела ответа. Это полезно для получения метаинформации, записанной в заголовках ответов, без необходимости транспортировать весь контент.
  • POST → запрашивает, чтобы сервер принял объект, включенный в запрос, в качестве нового подчиненного веб-ресурса, идентифицированного URI. Размещенные данные могут быть, например, аннотацией для существующих ресурсов; сообщение для доски объявлений, группы новостей, списка рассылки или ветки комментариев; блок данных, который является результатом отправки веб-формы в процесс обработки данных; или элемент для добавления в базу данных.
  • PUT → запрашивает, чтобы закрытый объект был сохранен под предоставленным URI. Если URI относится к уже существующему ресурсу, он изменяется; если URI не указывает на существующий ресурс, то сервер может создать ресурс с этим URI.
  • DELETE → удаляет указанный ресурс.
  • TRACE → повторяет полученный запрос, чтобы клиент мог видеть, какие (если есть) изменения или дополнения были сделаны промежуточными серверами.
  • OPTIONS → возвращает методы HTTP, которые сервер поддерживает для указанного URL.Это можно использовать для проверки функциональности веб-сервера, запросив «*» вместо конкретного ресурса.
  • CONNECT → преобразует соединение запроса в прозрачный туннель TCP / IP, обычно для облегчения связи с шифрованием SSL (HTTPS) через незашифрованный HTTP-прокси. См. Метод HTTP CONNECT.
  • PATCH → Метод PATCH применяет частичные изменения к ресурсу.

Подробнее о командах см .: [ RFC 7231 HTTP / 1.1: семантика и контент Автор IETF.На https://tools.ietf.org/html/rfc7231, по состоянию на 02 апреля 2016 г.]

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

В ответном сообщении сервера первая строка — это строка состояния. Вот пример:

HTTP / 1.1 200 ОК

Он состоит из 3 частей: ① версия HTTP. ② код состояния. ③ Удобочитаемое представление кода состояния.

Код состояния состоит из 3 цифр. Его значение сгруппировано по категориям по первой цифре:

.

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

Вот полный список.Чаще всего используются знаки со знаком.

  • 100 → Продолжить
  • 101 → Протоколы переключения
  • 200 → 🌟 ОК
  • 201 → Создано
  • 202 → Принято
  • 203 → Не авторитетная информация
  • 204 → Нет содержимого
  • 205 → Сбросить содержимое
  • 206 → Частичное содержимое
  • 300 → множественный выбор
  • 301 → 🌟 Перемещено навсегда
  • 302 → Найдено
  • 303 → См. Другие
  • 304 → без изменений
  • 305 → Использовать прокси
  • 307 → Временное перенаправление
  • 400 → неверный запрос
  • 401 → Неавторизованный
  • 402 → Требуется оплата
  • 403 → 🌟 Запрещено
  • 404 → 🌟 Не найдено
  • 405 → Метод запрещен
  • 406 → Неприемлемо
  • 407 → Требуется проверка подлинности прокси
  • 408 → Тайм-аут запроса
  • 409 → конфликт
  • 410 → ушел
  • 411 → Требуемая длина
  • 412 → Ошибка предварительного условия
  • 413 → Слишком большая полезная нагрузка
  • 414 → URI слишком длинный
  • 415 → Неподдерживаемый тип носителя
  • 416 → Неудовлетворительный диапазон
  • 417 → Неудачное ожидание
  • 426 → требуется обновление
  • 500 → Внутренняя ошибка сервера
  • 501 → Не реализовано
  • 502 → Плохой шлюз
  • 503 → Служба недоступна
  • 504 → Тайм-аут шлюза
  • 505 → Версия HTTP не поддерживается

Подробные сведения обо всех кодах состояния см .: [ RFC 7231 HTTP / 1.1: Семантика и содержание По IETF. На https://tools.ietf.org/html/rfc7231, по состоянию на 02 апреля 2016 г.]

Файлы cookie HTTP

Файлы cookie также отправляются как часть заголовка HTTP.

Что такое куки?

Обычно, когда сервер отвечает, он может вернуть заголовок, например
Set-Cookie: имя = значение .
Когда браузер видит это, он должен хранить его локально вместе с
с какого сервера пришел cookie. Когда браузер делает запрос к
сервер, браузер также должен отправлять все файлы cookie, отправленные тем же сервером
перед.

Целью файлов cookie является сохранение сервером состояний клиентов. За
Например, установив файл cookie, сервер может узнать,
пользователь авторизован.

Подробнее о работе файлов cookie см .:

JavaScript: проверка, получение, настройка, файлы cookie

Пакет протоколов TCP / IP

Протокол HTTP — это протокол высокого уровня прикладного уровня
Набор интернет-протоколов TCP / IP. Протокол HTTP предназначен для обмена клиент / сервер
Сообщения.

Но как именно браузер находит сервер по всему миру? и как
браузер отправляет сообщение именно самолетом?

Подробная информация о том, как взаимодействуют клиент / сервер, определяется многими низшими протоколами TCP / IP. Для базового введения см. Руководство по TCP / IP для начинающих.
.

Номер ссылки

  • RFC 7230, HTTP / 1.1: синтаксис сообщений и маршрутизация.
  • RFC 7231, HTTP / 1.1: семантика и содержание.
  • RFC 7232, HTTP / 1.1: Условные запросы.
  • RFC 7233, HTTP / 1.1: запросы диапазона.
  • RFC 7234, HTTP / 1.1: кэширование.
  • RFC 7235, HTTP / 1.1: аутентификация.
  • RFC 2817 Обновление до TLS в HTTP / 1.1.
  • RFC 5785 Определение общеизвестных универсальных идентификаторов ресурсов (URI).
  • RFC 6266 Использование поля заголовка Content-Disposition в протоколе передачи гипертекста (HTTP).
  • RFC 6585 Дополнительные коды состояния HTTP.

HTTP / 2 [ Протокол передачи гипертекста версии 2 (HTTP / 2) По IETF. На https://tools.ietf.org/html/rfc7540, по состоянию на 01.04.2016]

устарело. [ Протокол передачи гипертекста — HTTP / 1.1 По IETF. На https://tools.ietf.org/html/rfc2616, дата обращения 02.04.2016]

Если у вас есть вопросы, положите 5 долларов на patreon и напишите мне.

.

HTTP — Обзор протокола передачи гипертекста

HTTP — Обзор протокола передачи гипертекста

Новости | HTTP
Деятельность | Технические характеристики | Программного обеспечения
| Переговоры | Списки рассылки | IETF | HTTP-расширения |
WebMux | HTTP-NG | Веб-характеристика | Фон

Теперь, когда и расширения HTTP, и HTTP / 1.1 являются стабильными спецификациями (на тот момент RFC2616), W3C
закрыл HTTP-действие.

Попытка пересмотреть HTTP / 1.1 началась в 2006 году, что привело к созданию IETF httpbis
Рабочая группа.Работа завершена публикацией RFC 723X (см. Ниже)

Рядом находится

Связанные протоколы


См. Также временную шкалу HTTP для более старых событий

Рабочая группа HTTP

Связанные протоколы

Структура расширения HTTP
Механизм расширения для HTTP, предназначенный для устранения напряженности
между частным соглашением и публичной спецификацией и для размещения
расширение HTTP-клиентов и серверов программными компонентами
Протокол мультиплексирования (MUX)
Проект предложения по внедрению поддержки асинхронного обмена сообщениями на
уровень ниже HTTP
Обработка
идентификаторы фрагментов в перенаправленных URL
Интернет-черновик с предложением решения проблемы, которую оставляет HTTP
неопределенные.
HTTP-NG — Протокол передачи гипертекста — Далее
Поколение
— бывшее мероприятие W3C по реинжинирингу основного протокола
архитектура с использованием модульности, простоты и многоуровневости.

Справочная информация

W3C предлагает сервер Jigsaw, написанный на Java и
клиентский API libwww — оба выпущены с полной
набор функций HTTP / 1.1, включая кеширование и постоянные соединения.
См. Вклады W3C с открытым исходным кодом для
подробнее.

Предварительная производительность HTTP / 1.1
Оценка Джима Геттиса
Производительность HTTP / 1.1
документ подробно объясняет эксперименты и был недавно
отправлено для публикации. Эта работа показывает, как можно получить столько же
коэффициент 10 в количестве пакетов и в 2 раза в скорости при использовании
Конвейерная обработка HTTP / 1.1. Самые ранние результаты были представлены на встрече IETF в Сан-Хосе,
Декабрь 1996 г., и более полные результаты на заседании Консультативного комитета W3C.
в Англии в январе.
Обзор новых функций HTTP / 1.1 и
изменения от HTTP / 1.0, Джим Геттис
Эта презентация дает хороший обзор новых функций. Это будет
время от времени обновляется по мере представления. Презентация также
доступно для Microsoft
PowerPoint
PEP — механизм расширения для HTTP
Авторы: Хенрик Фристик Нильсен и Рохит Кхаре
Эта презентация была представлена ​​на встрече IETF в
Монреаль, июнь 1996 года.

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

[email protected] (Архивировано в W3C (см. Также
с 1994 по
Архив 2002 г.).
Официальный список рассылки рабочей группы IETF HTTP.
w3c-http @ w3.org (Архив)
Это список рассылки W3C, посвященный продвижению HTTP / 1.1.
реализации, чтобы получить достаточный опыт среди членов W3C для
поддержка спецификации и простота
разработка программного обеспечения и приложений HTTP / 1.1. Список только
доступен для членов W3C.
[email protected] (Архив)
Это основной общедоступный список рассылки для технических
обсуждение среди разработчиков программного обеспечения World Wide Web.Это
явно предназначен для совместного проектирования новых систем,
программное обеспечение, протоколы и документация, которые могут быть полезны для WWW
Сообщество разработчиков. Общие вопросы от не разработчиков должны быть
одна из многих групп новостей.
[email protected] (информация)
Этот список больше не поддерживается и больше не активен.
Не отправляйте письма на этот адрес!

См. Также информацию о HTTP-NG

Инженерная группа Интернета
(IETF) — это подразделение, занимающееся проектированием и разработкой протоколов в Интернете.В
IETF — это большое открытое международное сообщество разработчиков сетей, операторов,
поставщики и исследователи, заинтересованные в развитии Интернета
архитектура и бесперебойная работа Интернета. Он открыт для любого
заинтересованное лицо.

Рабочие группы, связанные с HTTP

Это рабочие группы IETF
работает над проблемами, напрямую связанными с HTTP:

Пол Хоффман в Internet Mail
Консорциум ведет отличный список рабочих групп IETF, напрямую связанных
в интернет-почту.Следующий список — это рабочие группы более удаленных
природа относительно HTTP.

Вы также можете проверить полный список работающих IETF
группы.

Встречи IETF

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

Лос-Анджелес , Калифорния, США, март-апрель 1998 г.
Где, как добраться,
повестка дня и т. д.
Вашингтон, округ Колумбия, США, декабрь 1997 г.
HTTP-WG
заметки с встречи и полный он-лайн
Поступления
Мюнхен, Германия, 11-15 августа 1997 г.
HTTP-WG
заметки с встречи и полный
on-line Труды
Мемфис, Теннесси, 7-11 апреля 1997 г.
HTTP-WG
заметки с встречи и полный он-лайн
Труды
Сан-Хосе, Калифорния, 9-13 декабря 1996 г.
HTTP-WG
заметки с встречи и полный
он-лайн слушания.
Монреаль, Квебек КАНАДА, 24-28 июня 1996 г.
HTTP-WG примечания от
встреча

Другие организации, связанные с IETF

Неупорядоченный список организаций, связанных с IETF:

  • Интернет-инженерия
    Руководящая группа (IESG), состоящая из директоров IETF Area
    вместе с председателем IETF.
  • The Internet Research Task Force
    (IRTF) состоит из целого ряда целенаправленных, долгосрочных небольших исследований.
    Группы.Эти группы работают над темами, связанными с интернет-протоколами,
    приложения, архитектура и технологии.
  • Совет по архитектуре Интернета
    (IAB) — это орган Internet Society, отвечающий за общие
    архитектурные соображения в Интернете.
  • Internet Society (ISOC) — это
    неправительственная Международная организация глобального сотрудничества и
    координация Интернета и его технологий межсетевого взаимодействия и
    Приложения.
  • Интернет-присвоенные номера
    Полномочия (IANA) являются центральным координатором по назначению
    уникальные значения параметров для интернет-протоколов

Ив Лафон
, @ (#) $ Id: Обзор.html, v 1.244 11.06.2014 14:21:46 ylafon Exp $

Авторские права © 1996-2003 гг.
W3C ® (MIT, ERCIM,
Кейо), все права защищены. Ответственность W3C, товарный знак, использование документов
и программное обеспечение
применяются правила лицензирования. Ваше взаимодействие с этим сайтом соответствует
с нашей общественностью и
Конфиденциальность участников
заявления.

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

2021 © Все права защищены. Карта сайта