Сегодня я слышал, что скоро протокол http2 будет реализован в современных браузерах. Дополнительная информация: https://en.wikipedia.org/wiki/HTTP/2, Я знаю, что Википедия — не лучший ресурс, но он немного подскажет, что происходит. Вопрос в том:
Как старые браузеры будут реагировать на заголовки http2?
Я имею ввиду на php (http://php.net) еще есть (26.02.2015) ссылка в функции заголовка (http://php.net/manual/en/function.header.php) к http1.1
Спецификация (http://www.faqs.org/rfcs/rfc2616). Я понимаю что в http2
все, что я должен сделать, это, например, изменить заголовок HTTP/1.1 404 Not Found
к чему-то похожему на HTTP/2.0 404 Not Found
, Но как на это отреагируют старые браузеры? Это прозрачно для веб-разработчиков и php-кодеров и реализовано на стороне браузера / сервера, или есть некоторые важные вещи / подсказки о совместимости?
Является ли использование заголовков http2 сразу после того, как они готовы, хорошей идеей?
Я не хочу никого обижать, но я знаю такой браузер, что его имя начинается с буквы I
и второй с буквой E
, что всегда может немного испортить. Боюсь, что новая спецификация полностью разрушит все старые версии этого браузера, и что это http2
, А мы — разработчики должны писать сайты, которые просто работают, где бы то ни было, и волшебство http2
сбудется через миллионы тонн исправлений / обновлений / месяцев проблем совместимости со старыми машинами.
В правильном вопросе должен быть какой-то код, так что вот оно :):
<?php
header("HTTP/2.0 404 Not Found"); // Am I correct? It will look like this?
?>
А как насчет старых браузеров в этом случае?
Это хорошая идея, чтобы использовать его сразу после того, как http2 жив?
Дополнительная документация:
В типичном сценарии клиент с поддержкой 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 неверный запрос любым сервером HTTP / 1.X. (Клиент может затем понизить запрос до HTTP / 1.1 и продолжить, например.)
Переписывание PHP-приложений для непосредственного использования HTTP / 2 займет немного больше работы, чем изменение header('HTTP/X.X...')
номера. Saikyr верно, HTTP / 2 — двоичный протокол; это означает, что мы будем использовать новую библиотеку для записи HTTP / 2 напрямую из PHP.
Отправка кода состояния и сообщения вместе с версией протокола больше не происходит. Вместо, псевдо-заголовки используются — в основном только заголовки с: впереди, чтобы не допустить столкновения с заголовками HTTP / 1.X. Однако заголовки не будут отправляться в виде открытого текста — разработана схема сжатия для преобразования заголовков в двоичные коды. HPACK проект 12. (Я не читал его; он меньше переворачивает страницы, чем 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 (что немыслимо, но мне кажется, что это вызовет больше проблем, чем решит).
Один из способов добавления поддержки HTTP / 2 — на уровне сервера / транспорта, с некоторым переводом заголовков HTTP / 1.1 в HTTP / 2. Модуль Apache может, вероятно, анализировать вывод HTML и обнаруживать связанные таблицы стилей, сценарии и изображения, генерируя PUSH_PROMISE для клиента при ответе на запрос. GET
запрос.
Основным преимуществом прямой поддержки HTTP / 2 в PHP было бы то, что ресурсы, с которыми они связаны, были «переданы» желающим клиентам, которые поддерживают эту функцию. Многие среды CMS на основе PHP смогут предоставлять список таблиц стилей, сценариев и изображений без необходимости повторного анализа выходных данных, предназначенных для клиента.
Я с нетерпением жду встречи с тем, что мы можем сделать!
Других решений пока нет …