The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлен новый код ответа HTTP - 103

31.10.2017 08:52

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, одобрил дополнение списка кодов состояния HTTP новым значением 103, которое предлагается использовать для упреждающего вывода заголовков. Документ с описанием кода 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=script

     HTTP/1.1 200 OK
     Date: Tue, 31 Oct 2017 5:03:15 GMT
     Content-Length: 1000
     Content-Type: text/html; charset=utf-8


  1. Главная ссылка к новости (http://www.ietf.org/mail-archi...)
  2. OpenNews: Протокол HTTP дополнен кодом 451 для обозначения запрещённых властями страниц
  3. OpenNews: Google предложил использовать HTTP-код 451 для уведомления о принудительном блокировании контента
  4. OpenNews: Впервые за 15 лет обновлена спецификация протокола HTTP/1.1
  5. OpenNews: Google отказывается от поддержки в Chrome протокола SPDY в пользу HTTP/2
  6. OpenNews: Разработчики HTTP/2.0 встроили в протокол напоминание о программе слежки
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47474-http
Ключевые слова: http
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним Анонимович Анонимов (?), 09:02, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    В 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-hints/?include_text=

    Будьте аккуратны при использовании этого заголовка. Такую-то возможность открыли для слежки за юзерами, фишингом, распространением всякой вирусни. Данный заголовок напомнил cross-domain ajax (я не говорю, что 1 в 1, просто напомнило).

     
     
  • 2.23, xm (ok), 11:56, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Паранойя чистой воды. В "1. Introduction" указано для чего HTTP 103 нужен. По-моему предельно понятно.
     
     
  • 3.28, пох (?), 12:36, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В "1. Introduction" указано для чего HTTP 103 нужен.

    вон в соседней новости - canvas тоже много для чего, казалось бы, нужен. А _используется_ - совершенно не для этого.

    И да, все эти "предзагрузки" и "оптимизации" на самом деле нахрен никому не нужны - на фоне отрисовки всей этой радости, миллисекундные задержки на скачивание еще одного файла никто и никогда не видит.

     
     
  • 4.32, Аноним (-), 13:51, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Часто в метро читаю статьи с habr-а, и я с вами не согласен, у них основная проблема это кучи г...на в придачу к посту, до загрузки которого ничего даже не начинает отрисовываться, и это в мобильной версии.
     
     
  • 5.35, Аноним (-), 15:34, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Т.е. roвнокод, который хреново работает на мобилках к проблеме отношения не имеет? Без адблока на главной 7мб rовна и 197 запросов, из них около 190 к сторонним ресурсам. новый тег конечно нужен чтобы исправить руки roвнокодеров.
     
     
  • 6.42, пох (?), 00:56, 01/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    главное - новый тег ничего и не исправит - пока все гуано не скачается, так ничего и не отрисуется, что с тегом, что без.
    А поскольку это графика и гигабайтные скрипты неведомой херни, качаться оно будет долго.

     
     
  • 7.45, Аноним (-), 09:12, 02/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не говоря уже о том, что "я часто читаю статьи с хабра" звучит как признание. Не говоря уже о том, что читает он там, но пишет-то здесь!
     
  • 4.40, xm (ok), 18:58, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У меня на HTTP/2 скорость загрузки сайта выше в 2-3 раза в зависимости от контента. Тут же пытаются в HTTP/1.1 втянуть что-то полезное. Надо, Федя, надо...
     

  • 1.4, X4asd (ok), 09:20, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а клиент не должен отправить в своих заголовках

    Expect: 103-early-hints

    ???

    что-то не нашёл упоминания такого в RFC

     
     
  • 2.7, Очередной аноним (?), 09:52, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зaшибись. Это теперь тот самописный быдлoкод, который выполнив запрос к серваку, ждет код 200 (или какие-то из 2XX) как успех (и идет по ветке обработки успеха), а все остальное - как терминальная/нетерминальная ошибка, теперь идет лесом? Надеюсь, что этот код ответа останется в обычном HTTP и не найдет никакого применения в распространенных веб-службах (платежных, почтовых (DHL, Hermes, RoyalMail...) и пр. системах).
     
     
  • 3.8, Очередной аноним (?), 09:57, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, стоп. Для HTTP-кодов группы 1xx там следующее правило (с википедии):

    "При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно."

     
     
  • 4.24, KonstantinB (ok), 11:58, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Цитата в данном случае по сути верная, но я бы все же рекомендовал читать RFC в оригинале, а не что там Рабинович напел в википедии.
     
  • 2.21, KonstantinB (ok), 11:54, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а клиент не должен отправить в своих заголовках
    > 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.

     
  • 2.29, пох (?), 12:40, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а клиент не должен отправить в своих заголовках
    > Expect: 103-early-hints

    там написано, что вообще-то может, и нежелательно http1.1 клиента кормить этим мусором если не отправлял, но в разделе "благие пожелания", а не в требованиях.

    Хотя правильнее всего было бы вообще весь этот шлак оставить http2, все равно его не жалко. (да и весь он написан ради "оптимизации" того, что совершенно незачем было оптимизировать, еще одна подобная ненужность была бы там как раз к месту)

    а http1.x оставить уже в покое, и не ломать совместимость с клиентами, не ожидающими мусорных заголовков 10x перед 200.

     

  • 1.5, Аноним (-), 09:22, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ура новому косяку - заголовок пришёл, а контент - нет.
     
  • 1.6, ixrws (??), 09:44, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!

    По сабжу, если приложение подгружает все основные ресурсы вначале работы, затем использует batсh запросы организованные как угодно, то эта хрень не нужна. Все ресурсы могут отдаваться скопом. В худшем случае можно придётся делать три запроса - один подготовительный, один для ресурсов, один основной. И это будет в десятки(зависит от количества ресурсов) быстрее с точки зрения задержек, чем при использовании сабжа, когда ресурсы продолжатся тянуться с разных источников разными запросами.

     
     
  • 2.10, я (?), 10:16, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ты так говоришь как будто где-то ютятся толпы безработных, высококвалифицированных инженеров, готовых проектировать приложения, гордо не идущих работать потому, что стоят дорого и ни копейкой меньше. А бизнес такой - ну их в пень этих дорогих инженеров, макаки стоят дешевле.
     
     
  • 3.41, Michael Shigorin (ok), 23:49, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ты так говоришь как будто где-то ютятся толпы безработных,
    > высококвалифицированных инженеров, готовых проектировать приложения,
    > гордо не идущих работать потому, что стоят дорого
    > и ни копейкой меньше.

    Сегодня с одним таким (причём ровно по описанию и мы оба это знаем) переписывался как раз.

    > А бизнес такой - ну их в пень этих дорогих инженеров, макаки стоят дешевле.

    Да нет, в общем-то -- но надо уметь приходить к _общему_ знаменателю совместно.

    К тому, что разное в жизни бывает.

     
     
  • 4.46, Аноним (-), 09:22, 02/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Знаменатель очень простой - угрозы бизнесу должны устранены, а значит персонал должен быть заменяем и в целях повышения конкурентоспособности должен стоить мало.

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

     
  • 2.18, a3k (?), 11:35, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!

    А ещё в мире много макак, которые считают себя Инженерами, а всех остальных - макаками.

     
     
  • 3.47, Аноним (-), 09:25, 02/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>Очередной костыль, лишь бы не нанимать инженеров, чтобы те проектировали приложения, а нанять тысячу макак, надеясь что они это сделают как-то так сами. Дороже же!
    > А ещё в мире много макак, которые считают себя Инженерами, а всех
    > остальных - макаками.

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

     

  • 1.12, qwerty_qwert1 (?), 10:23, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Server response:

         HTTP/1.1 103 Early Hints
         Link: </style.css>; rel=preload; as=style
         Link: </script.js>; rel=preload; as=script

         HTTP/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.
    Вот зачем это все так и не понял.

     
     
  • 2.22, Очередной аноним (?), 11:55, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В целом нечего страшного, надо только переписать http киент что бы после
    > 103 он еще ждал 200.
    > Вот зачем это все так и не понял.

    Если Вы используете HTTP 1.1, а не 1.0, то Вам еще и после 100,101,102 кодов можно пытаться ждать 200-ый. Это целая группа кодов, обозванная в википедии как "Информационные" (ссылка на статью дана в новости). Забавно расписан 100-ый код:

    100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

     

  • 1.13, h31 (ok), 10:40, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Объясните, в чем проблема выдать заголовки сразу, а потом отправить саму страницу с помощью chunked-ответа по мере готовности?
     
     
  • 2.14, я (?), 10:49, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Объясните, в чем проблема выдать заголовки сразу, а потом отправить саму страницу
    > с помощью chunked-ответа по мере готовности?

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

    Они и предлагают добавить к 200 метод 103, чтобы ты мог передать заголовки, которые известны заранее.

     
     
  • 3.31, Аноним (-), 13:44, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Если не имеются все заголовки, не известно что нужно отобразить и потребуется ли таблица стилей и картинки вообще. А поскольку вся статика кэшируется, нет вообще никакого смысла усложнять и воротить костыли.
    Если страница долго генерируется, надо смотреть, разбираться в чем проблема, и решать её. Страница должна генерироваться быстро.
    Если страница медленно передается - есть новые технологии, например QML в байткоде, есть новые алгоритмы сжатия, например ZSTD. Нужно внедрять их, а не костыли.
     
     
  • 4.33, Аноним (-), 13:57, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Страница должна генерироваться быстро.

    Кому?
    Нет я серьёзно, страница то может содержать разные данные, к примеру результат из хранимки в какой-либо БД, и выводить заголовок а потом тянуть содержимое нет никакого бизнес смысла.

     
  • 4.43, пох (?), 01:02, 01/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > ли таблица стилей и картинки вообще. А поскольку вся статика кэшируется,

    вот тут вы ошибаетесь. Кэшироваться-то она кэшируется, только (если это не мордокнига с нестандартным расширением) все равно мы будем отправлять запрос if-modified-since.
    А это tcp сессия в полном объеме, причем, поскольку модно cdn'ы и непременнейше код jquery конкретной версии качать с jquery.com, а не скопировать к себе, никакой http2 не спасет, соединение нужно не с твоим сервером, а с кучей чужих.
    Причем именно в этот момент канал у тебя забит потоком отдаваемого с сервера собственного контента, если он достаточно большой, то ждать этих сессий мы будем вполне заметное время.

    Естественно, никак решить эту проблему никакой 103й код не сможет.

     
  • 3.37, Аноним (-), 15:57, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в том, что для 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).

     

  • 1.15, Аноним (-), 11:18, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Предлагается несколько response на один request? Это что теперь - всех клиентов переписывать?
     
     
  • 2.19, KonstantinB (ok), 11:44, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Нет, не надо ничего переписывать. Некорректные реализации, которые не умеют обрабатывать 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.

     
     
  • 3.27, Аноним (-), 12:09, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    спс, т.е. 1xx и раньше подразумевались как information и клиенты должны были их пропускать для получения "нормального" (2+xx) ответа
     
  • 2.26, Очередной аноним (?), 12:03, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Предлагается несколько response на один request? Это что теперь - всех клиентов
    > переписывать?

    Походу только тех, которые претендуют на поддержку HTTP/1.1

     

  • 1.17, Ydro (?), 11:20, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Н-н-а-д-а в заголовок ещё добавить целиком контент страницы для упреждающего чтения :))
     
     
  • 2.30, пох (?), 12:44, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Н-н-а-д-а в заголовок ещё добавить целиком контент страницы для упреждающего чтения :))

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

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


     

  • 1.20, xm (ok), 11:52, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Обратите внимание, что автор драфта Казухо Оку, который известен своим HTTP/2 сервером H2O. Т.е. в новой версии ждём.
     
     
  • 2.34, Аноним (-), 14:27, 31/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Единственный полезный комментарий в этом гадюшнике
     
     
  • 3.48, Аноним (-), 09:29, 02/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Единственный полезный комментарий в этом гадюшнике

    Преврати гадюшник в цветник, напиши хоть что-то дельное.

     

  • 1.36, manster (ok), 15:49, 31/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Сейчас, типичного бота можно обнаружить по запросу html-страницы, содержащую различные ссылки (картинки, CSS, js ...) так: если после запроса страницы, эти ссылки не запрашивались, то это скорее всего бот.

    Обработка хинтов, будет более характерна для браузеров.

     
     
  • 2.49, А.Нонимус (?), 16:28, 02/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну конечно - а если бровсер уже нашёл эти картинки и скрипты у себя в кеше - то он после этого бот?
     
     
  • 3.50, manster (ok), 05:40, 03/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    запросы с кэшированным контентом могут маркироваться кукой
     
     
  • 4.51, arisu (ok), 20:35, 06/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот из‐та таких гениев кода, как ты, каждый гуаносайт норовит напихать мне печенек. и куча из них ещё и отказывается работать, если я их печеньки не ем. а ведь ваши родители могли бы вместо чтобы делать детей — подметать улицы, например. и всем бы польза была…
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру