В типичном сценарии клиент с поддержкой HTTP/2, связывающийся с сервером, сначала делает это, используя соединение HTTP/1.1, используя заголовок Upgrade: для указания доступности поддержки HTTP/2.
Это выглядит примерно так:
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
Источник: HTTP/2 черновик 17, раздел 3.2
Я цитирую спецификации прямо там, поэтому реальный запрос от реального клиента будет выглядеть немного сложнее — он также будет включать обычные заголовки HTTP/1.1, так что сервер, не желающий обновляться до HTTP/2, может просто продолжить с запросом. Сервер, не поддерживающий HTTP/2, просто игнорирует заголовки Upgrade: h2c и HTTP2-Settings: ....
Серверы, обновляющие соединение до HTTP/2, отвечают:
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
PRI * HTTP/2.0
SM
Источник: HTTP/2 черновик 17, раздел 3.2.
Этот раздел, начинающийся с PRI *, называется «предисловие к клиентскому соединению» и отправляется в начале любого соединения HTTP/2. Он разработан как строка, на которую не ответит ни один сервер HTTP/1.0 или /1.1. Это означает, что даже в нетипичном сценарии, когда у браузера есть основания полагать, что сервер поддерживает HTTP/2 перед подключением (например, мы говорим об интранет-среде с объявлением службы через другие протоколы), клиент HTTP/2 откроет соединение с "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n" и будет немедленно отклонено с ошибкой HTTP/1.1 400 Bad Request любым сервером HTTP/1.X. (Затем клиент может понизить запрос до HTTP/1.1 и продолжить, например.)
Переписывание PHP-приложений для прямого использования HTTP/2 потребует гораздо больше работы, чем изменение header('HTTP/X.X...') чисел. Сайкир прав, HTTP/2 — это бинарный протокол; это означает, что мы будем использовать новую библиотеку для написания HTTP/2 непосредственно из PHP.
Отправка кода состояния и сообщения вместе с версией протокола больше не происходит. Вместо этого используются псевдозаголовки — в основном просто заголовки с : впереди, чтобы избежать конфликтов с заголовками HTTP/1.X. Однако заголовки не будут передаваться в открытом виде — для преобразования заголовков в двоичные коды разработана схема сжатия. черновик 12 HPACK (я его не читал ; это менее увлекательно, чем HTTP/2.)
Итак, вместо header("HTTP/2 404 Not Found"); вы сделаете что-то вроде этого:
\HTTP2::setHeader(':status','404');
или вместо header("Location: $PROTO://$HOST$PATH");
\HTTP2::setHeader('location', "$PROTO://$HOST$PATH");
Я пока не знаю о такой поддержке в PHP, поэтому немного предполагаю. Я не уверен, сможет ли PHP получить достаточный контроль над соединением Apache, чтобы перейти с HTTP/2 и управлять самим соединением. Поскольку в Apache добавлена поддержка, у PHP может появиться возможность подключиться на уровне библиотеки. Какой бы ни была новая библиотека, она все еще может быть способна записывать заголовки соединения HTTP/1.1, в зависимости от клиента, но для этого потребуется переписать программное обеспечение, если они не решат header() повторно анализировать каждый аргумент для HTTP/2. output (что вполне возможно, но мне кажется, что это вызовет больше проблем, чем решит).
Одним из способов добавления поддержки HTTP/2 может быть уровень сервера/транспорта с некоторым переводом заголовков HTTP/1.1 в HTTP/2. Модуль Apache мог бы предположительно анализировать вывод HTML и обнаруживать связанные таблицы стилей, сценарии и изображения, генерируя PUSH_PROMISE для клиента при ответе на запрос GET.
Основное преимущество поддержки HTTP/2 непосредственно в PHP заключается в том, что ресурсы, на которые указывают ссылки, могут быть «перенаправлены» желающим клиентам, которые поддерживают эту функцию. Многие среды CMS на основе PHP могут предоставить список таблиц стилей, сценариев и изображений без необходимости повторного анализа вывода, предназначенного для клиента.
Я с нетерпением жду возможности увидеть, что мы можем сделать!
person
Andy Holland
schedule
26.02.2015
