HTTP протокол¶

См.также

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

HTTP является протоколом передачи данных 4го (прикладного) уровня стека протоколов TCP/IP. Так же может выступать в роли транспорта для других протоколов прикладного уровня, например: SOAP, XML-RPC, JSON-RPC, WebDAV. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

HTTP запрос и ответ

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

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

Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

См.также

URL¶

См.также

https://ru.wikipedia.org/wiki/URL

URL (Uniform Resource Locator) – унифицированный указатель на ресурс.

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

Дерево доступных ресурсов сайта

Ресурсы представляют из себя либо реальные файлы на сервере, например: HTML, js, png, …, либо логические сущности, которые генерируют содержимое на лету (в момент поступления запроса), например: список новостей, погода, фотогалерея, каталог товаров и прочее. Соответственно такие ресурсы называют статическими (неизменными) или динамическими.

Еще существуют абстрактные ресурсы, которые присутствуют в пути но этот адрес самостоятельно не существует, например:

http://example.com/ – главная страница сайта
http://example.com/blog/ – список статей
http://example.com/blog/article/1 – статья 1 в блоге
http://example.com/blog/article/ – абстрактный ресурс, который присутствует в пути, но реально его не существует. По данной ссылке сервер вернет ошибку 404 Not Found. Такие ресурсы нужны для большей читаемости URL и семантического разделения сущностей.

URI¶

См.также

URL является подмножеством более широкого термина URI (Uniform Resource Identifier), который обобщает вид различных идентификаторов.

Примеры URI:

ldap://[2001:db8::7]/c=GB?objectClass?one

mailto:John.Doe@example.com

news:comp.infosystems.www.servers.unix

tel:+1-816-555-1212

telnet://192.0.2.16:80/

ftp://ftp.is.co.za/rfc/rfc1808.txt

http://www.ietf.org/rfc/rfc2396.txt

urn:oasis:names:specification:docbook:dtd:xml:4.1.2

URN¶

См.также

https://ru.wikipedia.org/wiki/URN

URN (Uniform Resource Name) - идентифицирует путь до ресурса.

Пример:

URI = http://lectureskpd.readthedocs.io/kpd/3.http.html#urn
URL = http://lectureskpd.readthedocs.io
URN = /kpd/3.http.html

Идентификатор ресурса можно представить в виде формулы:

URI = URL + URN

Примечание

В обществе URI часто назвают как URL.

Структура URL¶

См.также

http://www.ietf.org/rfc/rfc3986.txt

Структура URL представлена на схеме ниже:

 foo://example.com:8042/over/there?name=ferret#nose
 \_/   \______________/\_________/ \_________/ \__/
  |           |            |            |        |
схема   имя(IP) и порт    путь        запрос   элемент
  |   _____________________|__
 / \ /                        \
 urn:example:animal:ferret:nose

Протокол¶

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

ws
ftp
http
https
file
mailto
xmpp

Авторизация¶

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

user:123
user

Адрес ресурса¶

<схема>://<логин>:<пароль>@ <хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

localhost:8080
yandex.ru
213.180.204.11
127.0.0.1:6543
yandex.ru:80
192.168.0.13:22

Пара <хост>:<порт> называется INET SOCKET или просто сокет, определяет входную точку приложения и идентифицирует адрес по которому с ним можно связаться.

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

Путь до ресурса¶

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

somedir/somefile.html

Параметры¶

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>? <параметры>#<якорь>

text=foobar&from=fx3&lr=213

Якорь¶

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры># <якорь>

someanchor

Якорь указывает на расположение в самом документе. Пример якоря http://lectureskpd.readthedocs.io/kpd/3.http.html#id10

Допустимые символы¶

Латинские буквы
Цифры
Специальные символы $-_.+!*“(),
Зарезервированные символы ; /? :@=&

Символ ; можно использовать вместо &

<a href="http://host/?x=1&y=2">
<a href="http://host/?x=1;y=2">

Форматы сообщений запроса/ответа¶

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

HTTP запрос и ответ

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

message = <Стартовая строка>
          *(<Заголовки>)
          CRLF
          [<Тело сообщения>]

Или

<Метод> <URI> HTTP/1.1
<Заголовки>
    Referer: http://www.yandex.ru/
</Заголовки>

<Тело сообщения>
    param=value&a=1&b=2&c=3
</Тело сообщения>

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

Пример запроса:

GET /ru/latest/net/http.html HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: lectureswww.readthedocs.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

Ответ:

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 26 Jan 2015 16:54:33 GMT
Content-Type: text/html
Content-Length: 48059
Last-Modified: Mon, 26 Jan 2015 16:22:21 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "54c669bd-bbbb"
X-Served: Nginx
X-Subdomain-TryFiles: True
X-Deity: hydra-lts
Accept-Ranges: bytes


<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
...

Стартовая строка запроса¶

для HTTP/0.9

GET <URI>

GET /foo/bar

для HTTP/1.0-1.1

<метод> <URI> HTTP/<версия>

GET /foo/bar2 HTTP/1.1

Методы¶

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

Существующие методы:

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

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

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

DELETE: служит для удаления существующего ресурса.

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

Также HTTP поддерживает и другие методы:

HEAD: аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Примечание

POST vs GET

http://phpfaq.ru/na_tanke#http

Определить, какой способ следует применять, очень просто. Если форма служит для запроса некой информации, например - при поиске, то ее следует отправлять методом GET. Чтобы можно было обновлять страницу, можно было поставить закладку и или послать ссылку другу. Если же в результате отправки формы данные записываются или изменяются на сервере, то следует их отправлять методом POST, причем обязательно после обработки формы надо перенаправить браузер методом GET. Так же, POST может понадобиться, если на сервер надо передать большой объём данных (у GET он сильно ограничен), а так же, если не следует «светить» передаваемые данные в адресной строке (при вводе логина и пароля, например).

В CGI скриптах

GET обычно передает в программу строку, через переменную окружения.
POST передает данные через стандартный поток ввода (stdin)

Метод GET¶

GET /index.php?param=value&a=1&b=2&c=3 HTTP/1.1
<Заголовки>

Метод POST¶

POST /index.php HTTP/1.1
<Заголовки>

<Тело сообщения>
    param=value&a=1&b=2&c=3
</Тело сообщения>

Стартовая строка ответа¶

HTTP/<версия> <код состояния> <пояснение>

HTTP/1.0 200 OK

Коды состояний¶

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

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.

204 No Content: в теле ответа нет сообщения.

205 Reset Content: указание серверу о сбросе представления документа.

206 Partial Content: ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

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

Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.

303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.

304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

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

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

400 Bad Request: вопрос был сформирован неверно.

401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.

403 Forbidden: сервер не открыл доступ к ресурсу.

405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.

409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

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

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.

503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Заголовки HTTP¶

См.также

https://ru.wikipedia.org/wiki/Список_заголовков_HTTP

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

Заголовков может быть несколько.

Все необходимые для функционирования HTTP заголовки описаны в основных RFC документах. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV.

Пример:

См.также

https://ru.wikipedia.org/wiki/Chunked_transfer_encoding

Основные заголовки

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

Заголовки сущности

HTTP/1.1 200 OK

Date: Mon, 17 Sep 2012 13:05:11 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Server: nginx
Vary: X-Real-SSL-Protocol

Content-Type: text/html; charset=UTF-8
Expires: Mon, 17 Sep 2012 13:05:11 GMT
Content-Encoding: gzip

Основные заголовки¶

См.также

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.5

General Headers («Основные заголовки») — должны включаться в любое сообщение клиента и сервера. Большая часть из них являются обязательными.

Cache-Control
Connection
Date
Pragma
Trailer
Transfer-Encoding
Upgrade
Via
Warning

Заголовок Via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки запроса¶

См.также

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3

Request Headers («Заголовки запроса») — используются только в запросах клиента.

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

Заголовки ответа¶

См.также

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.2

Response Headers («Заголовки ответа») — только для ответов от сервера.

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

Заголовки сущности¶

См.также

http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1

Allow
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified

Entity Headers («Заголовки сущности») — В заголовках сущностей передаётся мета-информация контента.

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

Нестандартные заголовки¶

X-Frame-Options

X-Frame-Options: DENY;
//запретит загрузку через <iframe>

X-Frame-Options: SAMEORIGIN;
//разрешит загрузку через <iframe>  но только если и <iframe>,
и страница, его загружающая, находятся на одном домене

X-Requested-With

X-Requested-With: XMLHttpRequest
// используется для идентификации ajax запросов

Пасхалки

// используются чтобы пошутить =)

X-Awesome: If you found this header please email us about a writing job

X-Konkurentam: Preved

X-ServerNickName: Wolverine

Пример HTTP в браузере¶

Открываем браузер и пишем адрес веб ресурса (URI)

Стартовое окно браузера

Браузер генерирует строку запроса и отправляет его на сервер

GET /ru/latest/net/http.html HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: lectureswww.readthedocs.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

HTTP запрос

Сервер получает текст запроса, обрабатывает его, формирует текст ответа и отправляет его клиенту.

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 26 Jan 2015 16:54:33 GMT
Content-Type: text/html
Content-Length: 48059
Last-Modified: Mon, 26 Jan 2015 16:22:21 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "54c669bd-bbbb"
X-Served: Nginx
X-Subdomain-TryFiles: True
X-Deity: hydra-lts
Accept-Ranges: bytes



<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>Протокол HTTP &mdash; Документация Основы Веб-программирования 0.0.0</title>

  <link href='https://fonts.googleapis.com/css?family=Lato:400,700,400italic,700italic|Roboto+Slab:400,700|Inconsolata:400,700' rel='stylesheet' type='text/css'>

    <link rel="stylesheet" href="https://media.readthedocs.org/css/sphinx_rtd_theme.css" type="text/css" />

    <link rel="stylesheet" href="https://media.readthedocs.org/css/readthedocs-doc-embed.css" type="text/css" />

    <link rel="top" title="Документация Основы Веб-программирования 0.0.0" href="../index.html"/>
        <link rel="up" title="Каналы передачи данных" href="index.html"/>
        <link rel="next" title="Сетевое программирование" href="../www.sync/codding.net.html"/>
        <link rel="prev" title="Сети" href="net.html"/>

<!-- RTD Extra Head -->
<!--
Read the Docs is acting as the canonical URL for your project.
If you want to change it, more info is available in our docs:
  http://docs.readthedocs.org/en/latest/canonical.html
-->
<link rel="canonical" href="http://lectureswww.readthedocs.org/ru/latest/net/http.html" />

<script type="text/javascript">
....


  </script>
</body>
</html>

HTTP ответ

Пример HTTP в консоле (telnet)¶

См.также

https://ru.wikipedia.org/wiki/Telnet

В этом примере сделаем все то же самое, что и в предыдущем. Только отправлять HTTP запрос будем при помощи утилиты telnet.

$ telnet readthedocs.org 80
Trying 162.209.114.75...
Connected to readthedocs.org.
Escape character is '^]'.
GET /ru/latest/net/http.html HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Host: lectureswww.readthedocs.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 26 Jan 2015 16:54:33 GMT
Content-Type: text/html
Content-Length: 48059
Last-Modified: Mon, 26 Jan 2015 16:22:21 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "54c669bd-bbbb"
X-Served: Nginx
X-Subdomain-TryFiles: True
X-Deity: hydra-lts
Accept-Ranges: bytes



<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>Протокол HTTP &mdash; Документация Основы Веб-программирования 0.0.0</title>

  <link href='https://fonts.googleapis.com/css?family=Lato:400,700,400italic,700italic|Roboto+Slab:400,700|Inconsolata:400,700' rel='stylesheet' type='text/css'>

    <link rel="stylesheet" href="https://media.readthedocs.org/css/sphinx_rtd_theme.css" type="text/css" />

    <link rel="stylesheet" href="https://media.readthedocs.org/css/readthedocs-doc-embed.css" type="text/css" />

    <link rel="top" title="Документация Основы Веб-программирования 0.0.0" href="../index.html"/>
        <link rel="up" title="Каналы передачи данных" href="index.html"/>
        <link rel="next" title="Сетевое программирование" href="../www.sync/codding.net.html"/>
        <link rel="prev" title="Сети" href="net.html"/>

<!-- RTD Extra Head -->
<!--
Read the Docs is acting as the canonical URL for your project.
If you want to change it, more info is available in our docs:
  http://docs.readthedocs.org/en/latest/canonical.html
-->
<link rel="canonical" href="http://lectureswww.readthedocs.org/ru/latest/net/http.html" />

<script type="text/javascript">
....


  </script>
</body>
</html>Connection closed by foreign host.

Для HTTPS протокола существуют утилиты openssl и gnutls:

$ openssl s_client -connect www.github.com:443

CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 5157550, street = "88 Colin P Kelly, Jr Street", postalCode = 94107, C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
verify return:1
---
Certificate chain
 0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=5157550/street=88 Colin P Kelly, Jr Street/postalCode=94107/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHeTCCBmGgAwIBAgIQC/20CQrXteZAwwsWyVKaJzANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDMxMDAwMDAwMFoXDTE4MDUxNzEy
FrBHTFxqIP6kDnxiLElBrZngtY07ietaYZVLQN/ETyqLQftsf8TecwTklbjvm8NT
JqbaIVifYwqwNN+4lRxS3F5lNlA/il12IOgbRioLI62o8G0DaEUQgHNf8vSG
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=5157550/street=88 Colin P Kelly, Jr Street/postalCode=94107/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=github.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3642 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 5C279816840984C46727CE47615397799B95838DDEC30066F78377A
    Session-ID-ctx:
    Master-Key: B4674BDA91A35C85D235F04026FDEAFA43FE312FCE27900E4110B8C1F
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1458670134
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET / HTTP/1.1
Host: github.com

HTTP/1.1 200 OK
Server: GitHub.com
Date: Tue, 22 Mar 2016 18:09:07 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
Cache-Control: no-cache
Vary: X-PJAX
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: logged_in=no; domain=.github.com; path=/; expires=Sat, 22 Mar 2036 18:09:07 -0000; secure; HttpOnly
Set-Cookie: _gh_sess=eyJzZXNzaW9uX2lkIjoiMjI1YjkyOWIxYTUxMjIzZGE1ZTk2MmI2Yjg0YTQ2YjQiLCJfY3NyZl90b2tlbiI6Inc2R0x0MW1MK3hvUHFFYlhzczZYNCtoTUtwTmVUTnlvTFE5UCtZUU5yWk09In0%3D--ae9efc5ffb8c6238d4cf0b08fb1516500fdee201; path=/; secure; HttpOnly
X-Request-Id: 7c453b185f653a7bd0af24df209ee2b4
X-Runtime: 0.009394
Content-Security-Policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com wss://live.github.com; font-src assets-cdn.github.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; frame-src render.githubusercontent.com; img-src 'self' data: assets-cdn.github.com identicons.github.com www.google-analytics.com collector.githubapp.com *.gravatar.com *.wp.com *.githubusercontent.com; media-src 'none'; object-src assets-cdn.github.com; plugin-types application/x-shockwave-flash; script-src assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Public-Key-Pins: max-age=300; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; pin-sha256="k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K+59sNQws="; pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q="; pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4="; pin-sha256="iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0="; pin-sha256="LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A="; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
Vary: Accept-Encoding
X-Served-By: a128136e4734a9f74c013356c773ece7
X-GitHub-Request-Id: 5E1FA660:3F8D:DE52100:56F18A36


<!DOCTYPE html>
<html lang="en" class="">
  <head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# object: http://ogp.me/ns/object# article: http://ogp.me/ns/article# profile: http://ogp.me/ns/profile#">
    <meta charset='utf-8'>

    <link crossorigin="anonymous" href="https://assets-cdn.github.com/assets/frameworks-d351435b5f1e212200389237dc222f117a71a35e056adc4556b00b152a9f79c4.css" media="all" rel="stylesheet" />
    <link crossorigin="anonymous" href="https://assets-cdn.github.com/assets/github-d6cdc916c67f2afd181c5dd292db1fdb3e93fc18d67b4a8cdac0ef77df6b9cc9.css" media="all" rel="stylesheet" />



    <link crossorigin="anonymous" href="https://assets-cdn.github.com/assets/site-cba73ccd3ee30bf3b90aaf16f1aad8d8f91886bd3bc7fa5b42abf46dd3c46210.css" media="all" rel="stylesheet" />

    <link as="script" href="https://assets-cdn.github.com/assets/frameworks-20e2831691c9bb0a4dc1bd778529fc1c16ec8c8a24b32d9964f984772d2eb24b.js" rel="preload" />
    <link as="script" href="https://assets-cdn.github.com/assets/github-ab1086948a3be528001710080ba17e4975ddb36a9379ab7dddfdb0370647b7c1.js" rel="preload" />

    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta http-equiv="Content-Language" content="en">
    <meta name="viewport" content="width=1020">


    <title>How people build software · GitHub</title>
    <link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="GitHub">
    <link rel="fluid-icon" href="https://github.com/fluidicon.png" title="GitHub">
    <link rel="apple-touch-icon" href="/apple-touch-icon.png">
    <link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png">
    <link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png">
    <link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png">
    <link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png">
    <link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png">
    <link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png">
    <link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png">
    <link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png">
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">
    <meta property="fb:app_id" content="1401488693436528">

$ gnutls-cli www.github.com

Пример HTTP в firebug¶

См.также

http://getfirebug.com/

FireBug - это плагин браузера FireFox для веб разработчиков. Запускается по клавише <F12>.

Заголовки запроса и ответа в FireBug’е из предыдущего примера.

Заголовки запроса в Firebug

Тело ответа находится в отдельной вкладке.

Тело ответа в Firebug

Резюме¶

Протокол HTTP это:

однонаправленный (запрос/ответ)
текстовый протокол
не хранит состояния
работает на сетевом уровне только через TCP
может передавать любые данные
используется не только в браузерах
обслуживает львиную долю Интернет трафика

Достоинства¶

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

Недостатки¶

Избыточность передаваемой информации, и как следствие, большой размер сообщений по сравнению с передачей двоичных данных. Это нивелируется внедрением кэширования на стороне клиента, компрессии передаваемых данных от сервера. Также улучшает ситуацию использование прокси-серверов, позволяющих передавать информацию клиенту с наиболее близкого сервера, diff-кодирование, благодаря которому клиенту передается не весь объем данных, а только измененная их часть.
Отсутствие навигации. У протокола отсутствую средства навигации среди ресурсов сервера. Клиент не может, как в FTP запросить список доступных файлов. Протокол предполагает, что пользователю уже известен URI интересующего его ресурса.

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

Карта сайта может использоваться как пользователем, так и роботами-пауками поисковых систем, уменьшая для них глубину просмотра—минимально необходимое количество переходов с главной страницы. Аналогичную функцию выполняют и файлы sitemap, но только для приложений. Данная проблема полностью решена в протоколе более высокго уровня WebDAV с помощью добавленного метода PROPFIND, который позволяет получить не только дерево каталогов, но и список параметров каждого ресурса.
Отсутствие поддержки распределённости. Изначально протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вовсе не приниматься в расчёт. Однако со временем стало очевидно, что при промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается непригоден. В связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next Generation), но этот протокол до сих пор находится на стадии разработки.

Каналы передачи данных

HTTP протокол¶

URL¶

URI¶

URN¶

Структура URL¶

Протокол¶

Авторизация¶

Адрес ресурса¶

Путь до ресурса¶

Параметры¶

Якорь¶

Допустимые символы¶

Форматы сообщений запроса/ответа¶

Стартовая строка запроса¶

Методы¶

Метод GET¶

Метод POST¶

Стартовая строка ответа¶

Коды состояний¶

Заголовки HTTP¶

Основные заголовки¶

Заголовки запроса¶

Заголовки ответа¶

Заголовки сущности¶

Нестандартные заголовки¶

Cookie¶

Пример HTTP в браузере¶

Пример HTTP в консоле (telnet)¶

Пример HTTP в firebug¶

Резюме¶

Достоинства¶

Недостатки¶