Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, одобрил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m... дополнение списка кодов состояния HTTP (https://ru.wikipedia.org/wiki/%D0%A1%D0%... новым значением 103, которое предлагается использовать для упреждающего вывода заголовков. Документ (https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hi... с описанием кода 103 позиционируется как экспериментальный RFC.
Код 103 позволяет информировать клиента о содержании некоторых HTTP-заголовков сразу после запроса, не дожидаясь пока сервер выполнит все связанные с запросом операции и начнёт отдачу контента. Подобным образом можно сообщать подсказки о связанных с отдаваемой страницей элементах, которые могут быть предварительно загружены (например, могут быть приведены ссылки на используемые на странице css и javascript). Получив информацию о подобных ресурсах браузер может приступить к их загрузке не дожидаясь окончания отдачи основной страницы, что позволяет сократить общее время обработки запроса.HTTP/1.1 103 Early Hints
Link: ‹/style.css›; rel=preload; as=style
Link: ‹/script.js›; rel=preload; as=scriptHTTP/1.1 200 OK
Date: Tue, 31 Oct 2017 5:03:15 GMT
Content-Length: 1000
Content-Type: text/html; charset=utf-8URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m...
Новость: http://www.opennet.me/opennews/art.shtml?num=47474
В RFC прямым текстом пишут:In particular, an HTTP/1.1 client that mishandles an informational
response as a final response is likely to consider all responses to
the succeeding requests sent over the same connection to be part of
the final response. Such behavior might constitute a cross-origin
information disclosure vulnerability in case the client multiplexes
requests to different origins onto a single persistent connection.https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hi...
Будьте аккуратны при использовании этого заголовка. Такую-то возможность открыли для слежки за юзерами, фишингом, распространением всякой вирусни. Данный заголовок напомнил cross-domain ajax (я не говорю, что 1 в 1, просто напомнило).
Паранойя чистой воды. В "1. Introduction" указано для чего HTTP 103 нужен. По-моему предельно понятно.
> В "1. Introduction" указано для чего HTTP 103 нужен.вон в соседней новости - canvas тоже много для чего, казалось бы, нужен. А _используется_ - совершенно не для этого.
И да, все эти "предзагрузки" и "оптимизации" на самом деле нахрен никому не нужны - на фоне отрисовки всей этой радости, миллисекундные задержки на скачивание еще одного файла никто и никогда не видит.
Часто в метро читаю статьи с habr-а, и я с вами не согласен, у них основная проблема это кучи г...на в придачу к посту, до загрузки которого ничего даже не начинает отрисовываться, и это в мобильной версии.
Т.е. roвнокод, который хреново работает на мобилках к проблеме отношения не имеет? Без адблока на главной 7мб rовна и 197 запросов, из них около 190 к сторонним ресурсам. новый тег конечно нужен чтобы исправить руки roвнокодеров.
главное - новый тег ничего и не исправит - пока все гуано не скачается, так ничего и не отрисуется, что с тегом, что без.
А поскольку это графика и гигабайтные скрипты неведомой херни, качаться оно будет долго.
Не говоря уже о том, что "я часто читаю статьи с хабра" звучит как признание. Не говоря уже о том, что читает он там, но пишет-то здесь!
У меня на HTTP/2 скорость загрузки сайта выше в 2-3 раза в зависимости от контента. Тут же пытаются в HTTP/1.1 втянуть что-то полезное. Надо, Федя, надо...
а клиент не должен отправить в своих заголовкахExpect: 103-early-hints
???
что-то не нашёл упоминания такого в RFC
Зaшибись. Это теперь тот самописный быдлoкод, который выполнив запрос к серваку, ждет код 200 (или какие-то из 2XX) как успех (и идет по ветке обработки успеха), а все остальное - как терминальная/нетерминальная ошибка, теперь идет лесом? Надеюсь, что этот код ответа останется в обычном HTTP и не найдет никакого применения в распространенных веб-службах (платежных, почтовых (DHL, Hermes, RoyalMail...) и пр. системах).
Хм, стоп. Для HTTP-кодов группы 1xx там следующее правило (с википедии):"При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно."
Цитата в данном случае по сути верная, но я бы все же рекомендовал читать RFC в оригинале, а не что там Рабинович напел в википедии.
> а клиент не должен отправить в своих заголовках
> Expect: 103-early-hints
> ???Нет.
В случае с 100-continue Expect нужен для того, чтобы сервер мог помимо continue сразу выдать ошибку (например, 413 Payload Too Large) сразу после чтения заголовков и был уверен, что клиент это поймет и не будет до получения 100 Continue слать гигабайты.
А случай с 103 прекрасно покрывается давно существующими пунктами RFC: rfc7231, section 6.2, и даже в древнем rfc 2616, section 10.1.
> а клиент не должен отправить в своих заголовках
> Expect: 103-early-hintsтам написано, что вообще-то может, и нежелательно http1.1 клиента кормить этим мусором если не отправлял, но в разделе "благие пожелания", а не в требованиях.
Хотя правильнее всего было бы вообще весь этот шлак оставить http2, все равно его не жалко. (да и весь он написан ради "оптимизации" того, что совершенно незачем было оптимизировать, еще одна подобная ненужность была бы там как раз к месту)
а http1.x оставить уже в покое, и не ломать совместимость с клиентами, не ожидающими мусорных заголовков 10x перед 200.
Ура новому косяку - заголовок пришёл, а контент - нет.
Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!По сабжу, если приложение подгружает все основные ресурсы вначале работы, затем использует batсh запросы организованные как угодно, то эта хрень не нужна. Все ресурсы могут отдаваться скопом. В худшем случае можно придётся делать три запроса - один подготовительный, один для ресурсов, один основной. И это будет в десятки(зависит от количества ресурсов) быстрее с точки зрения задержек, чем при использовании сабжа, когда ресурсы продолжатся тянуться с разных источников разными запросами.
ты так говоришь как будто где-то ютятся толпы безработных, высококвалифицированных инженеров, готовых проектировать приложения, гордо не идущих работать потому, что стоят дорого и ни копейкой меньше. А бизнес такой - ну их в пень этих дорогих инженеров, макаки стоят дешевле.
> ты так говоришь как будто где-то ютятся толпы безработных,
> высококвалифицированных инженеров, готовых проектировать приложения,
> гордо не идущих работать потому, что стоят дорого
> и ни копейкой меньше.Сегодня с одним таким (причём ровно по описанию и мы оба это знаем) переписывался как раз.
> А бизнес такой - ну их в пень этих дорогих инженеров, макаки стоят дешевле.
Да нет, в общем-то -- но надо уметь приходить к _общему_ знаменателю совместно.
К тому, что разное в жизни бывает.
Знаменатель очень простой - угрозы бизнесу должны устранены, а значит персонал должен быть заменяем и в целях повышения конкурентоспособности должен стоить мало.Про то, что в жизни всякое бывает - очень глубокомысленно.
>Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!А ещё в мире много макак, которые считают себя Инженерами, а всех остальных - макаками.
>>Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!
> А ещё в мире много макак, которые считают себя Инженерами, а всех
> остальных - макаками.в точку. всяк другого мнит уродом, не смотря, что сам урод.
спроси тут какая ось единственно правильная, сразу набегут.
Server response:HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=scriptHTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script<!doctype html>
[... rest of the response body is omitted from the example ...]В целом нечего страшного, надо только переписать http киент что бы после 103 он еще ждал 200.
Вот зачем это все так и не понял.
> В целом нечего страшного, надо только переписать http киент что бы после
> 103 он еще ждал 200.
> Вот зачем это все так и не понял.Если Вы используете HTTP 1.1, а не 1.0, то Вам еще и после 100,101,102 кодов можно пытаться ждать 200-ый. Это целая группа кодов, обозванная в википедии как "Информационные" (ссылка на статью дана в новости). Забавно расписан 100-ый код:
100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
Объясните, в чем проблема выдать заголовки сразу, а потом отправить саму страницу с помощью chunked-ответа по мере готовности?
> Объясните, в чем проблема выдать заголовки сразу, а потом отправить саму страницу
> с помощью chunked-ответа по мере готовности?в том, что для 200 тебе нужно уже знать все заголовки для ответа потому, а приложение может еще не иметь всех заголовков для полноценного ответа.
Они и предлагают добавить к 200 метод 103, чтобы ты мог передать заголовки, которые известны заранее.
Если не имеются все заголовки, не известно что нужно отобразить и потребуется ли таблица стилей и картинки вообще. А поскольку вся статика кэшируется, нет вообще никакого смысла усложнять и воротить костыли.
Если страница долго генерируется, надо смотреть, разбираться в чем проблема, и решать её. Страница должна генерироваться быстро.
Если страница медленно передается - есть новые технологии, например QML в байткоде, есть новые алгоритмы сжатия, например ZSTD. Нужно внедрять их, а не костыли.
> Страница должна генерироваться быстро.Кому?
Нет я серьёзно, страница то может содержать разные данные, к примеру результат из хранимки в какой-либо БД, и выводить заголовок а потом тянуть содержимое нет никакого бизнес смысла.
> ли таблица стилей и картинки вообще. А поскольку вся статика кэшируется,вот тут вы ошибаетесь. Кэшироваться-то она кэшируется, только (если это не мордокнига с нестандартным расширением) все равно мы будем отправлять запрос if-modified-since.
А это tcp сессия в полном объеме, причем, поскольку модно cdn'ы и непременнейше код jquery конкретной версии качать с jquery.com, а не скопировать к себе, никакой http2 не спасет, соединение нужно не с твоим сервером, а с кучей чужих.
Причем именно в этот момент канал у тебя забит потоком отдаваемого с сервера собственного контента, если он достаточно большой, то ждать этих сессий мы будем вполне заметное время.Естественно, никак решить эту проблему никакой 103й код не сможет.
> в том, что для 200 тебе нужно уже знать все заголовки для ответа потому, а приложение может еще не иметь всех заголовков для полноценного ответа.HTTP/1.1 200 OK
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
// тут повисаем для генерации страницы
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8<!doctype html>
Нестыковка может быть только при условии, что ты не сможешь 200-й код нагенерить (например, получится 503).
Предлагается несколько response на один request? Это что теперь - всех клиентов переписывать?
Нет, не надо ничего переписывать. Некорректные реализации, которые не умеют обрабатывать informational responses, надо править, да.RFC 7231
6.2. Informational 1xx
[...]
A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses.
спс, т.е. 1xx и раньше подразумевались как information и клиенты должны были их пропускать для получения "нормального" (2+xx) ответа
> Предлагается несколько response на один request? Это что теперь - всех клиентов
> переписывать?Походу только тех, которые претендуют на поддержку HTTP/1.1
Н-н-а-д-а в заголовок ещё добавить целиком контент страницы для упреждающего чтения :))
> Н-н-а-д-а в заголовок ещё добавить целиком контент страницы для упреждающего чтения :))нет, там вся идея "оптимизации" в том, что сервер слишком долго думает, когда этот контент генерит, и давайте, чтоб юзеру было нескучно, займем пока его браузер какой-нибудь бесполезной работой. А то еще вообще по таймауту отвалится.
Оптимизировать сам код, чтобы не тупил часами или хотя бы использовал для этого предназначенные технологии - не, не наш путь.
Обратите внимание, что автор драфта Казухо Оку, который известен своим HTTP/2 сервером H2O. Т.е. в новой версии ждём.
Единственный полезный комментарий в этом гадюшнике
> Единственный полезный комментарий в этом гадюшникеПреврати гадюшник в цветник, напиши хоть что-то дельное.
Сейчас, типичного бота можно обнаружить по запросу html-страницы, содержащую различные ссылки (картинки, CSS, js ...) так: если после запроса страницы, эти ссылки не запрашивались, то это скорее всего бот.Обработка хинтов, будет более характерна для браузеров.
Ну конечно - а если бровсер уже нашёл эти картинки и скрипты у себя в кеше - то он после этого бот?
запросы с кэшированным контентом могут маркироваться кукой
вот из‐та таких гениев кода, как ты, каждый гуаносайт норовит напихать мне печенек. и куча из них ещё и отказывается работать, если я их печеньки не ем. а ведь ваши родители могли бы вместо чтобы делать детей — подметать улицы, например. и всем бы польза была…