The OpenNET Project / Index page

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

Впервые за 15 лет обновлена спецификация протокола HTTP/1.1

07.06.2014 21:03

Инженерный комитет IETF (Internet Engineering Task Force), занимающегося развитием протоколов и архитектуры сети Интернет, признал устаревшим выпущенный в 1999 году RFC 2616, определяющий протокол HTTP/1.1. Аналогичная судьба постигла RFC 2617, определяющий механизмы аутентификации HTTP. Для описания HTTP/1.1 представлена серия новых RFC, учитывающих современные реалии (например, в 1999 году не предполагалось внебраузерное применение HTTP (HTTP API), появление AJAX и методов HTML5):

На подготовку обновления спецификации HTTP/1.1 ушло семь лет, было выпущено 26 предварительных черновиков, внесено более 2600 изменений, устранено 550 недоработок. Обновления были разработаны участниками группы HTTPBis, также ответственной за создание стандарта HTTP/2.0. Разделение спецификации на группу отдельных RFC произведено с целью оптимизации будущей спецификации HTTP/2.0, в которой теперь можно сослаться на типовые не изменившиеся технологии, вместо их переопределения. При этом, по отдельности документы более компактны, в то время как старый RFС состоял из 176 страниц. Описание элементов HTTP/1.1 значительно упрощено для восприятия и детализировано. Из текста исключены двусмысленные формулировки.

Из нововведений можно выделить:

  • Стандартизован 308 код статуса выполнения запроса, определяющий механизм постоянного перенаправления (permanent redirect). В отличие от кода 301 (Moved Permanently), при получении кода 308 клиенту запрещается менять текущий метод запроса (при 301 метод обычно менялся на GET);
  • Приведена к устоявшейся практике логика реакции на коды статуса 301 и 302, которая теперь подразумевает смену метода с POST на GET;
  • Стандартизован заголовок Forwarded для сохранения IP-адреса оригинального запроса после проброса соединения через прокси или балансировщик нагрузки. Forwarded пришёл на замену таким заголовкам, как X-Forwarded-For и X-Forwarded-Proto;
  • Явно определено поведение при наличии непредусмотренных символов пробела и запрещено разбиение содержимого заголовков на несколько строк, что должно исключить появление уязвимостей, манипулирующих разделением запроса;
  • Снято ограничение на два одновременных соединения к серверу;
  • Прекращена поддержка HTTP/0.9;
  • Удалено требование к использованию ISO-8859-1 как кодировки по умолчанию;
  • Снято требование по обязательной обработке всех полей заголовков Content-*;
  • Запрещено использование Content-Range в PUT-запросах;
  • В качестве значения Referer при открытии страницы с нуля рекомендовано использовать "about:blank", что позволит отделить запросы без перехода от запросов с запрещённым Referer;
  • Определена допустимость кэширования для кодов 204, 404, 405, 414 и 501;
  • Содержимое заголовка Location теперь может задаваться относительно текущего URI;
  • Удалена поддержка заголовка Content-MD5.


  1. Главная ссылка к новости (https://www.mnot.net/blog/2014...)
  2. OpenNews: Доступен второй черновой вариант спецификации HTTP 2.0
  3. OpenNews: Опубликован первый черновик спецификации HTTP 2.00
  4. OpenNews: В протоколе HTTP/2.0 предложено перейти к обязательному использованию HTTPS для всех соединений
  5. OpenNews: Представители IETF предложили перевести Tor в категорию стандартов интернет
Лицензия: CC-BY
Тип: Интересно / К сведению
Ключевые слова: http, web
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:49, 07/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +19 +/
    А где код 451, актуальный и злободневный?
     
     
  • 2.31, Аноним (-), 16:36, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Хорошие люди попросили не делать.
    Зачем попусту народ беспокоить. Пустое это.
     
  • 2.40, A. (?), 11:20, 13/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А я чего-то сразу про 418 вспомнил
     

  • 1.2, Аноним (-), 22:51, 07/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Удалено требование к использованию ISO-8859-1 как кодировки по умолчанию

    А было такое требование? Ну, знаете.

     
     
  • 2.33, Аноним (-), 21:31, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    15 лет назад это казалось круто.
     

  • 1.4, ЫыВ (?), 23:16, 07/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ура! дожил!
     
  • 1.9, Аноним (-), 00:24, 08/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    о елки.
    ни хтмл5 и выше - стандартом не стали, ни вебсокеты :(
    но за что спасибо - выпилили 0.9 хоть, вместе с 8859-1, музейные/багучие.
     
     
  • 2.41, qux (ok), 15:35, 15/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > о елки.
    > ни хтмл5 и выше - стандартом не стали, ни вебсокеты :(

    Причем HTML к стандартизации HTTP?

     

  • 1.10, Аноним (-), 00:25, 08/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а чем им Content-MD5 не угодил ? АНБ? :=/
     
     
  • 2.11, Аноним (-), 00:54, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Фича оказалась беполезной. Плюс на сегодня, MD5 в чистом виде использовать опасно/не рекомендуется.
     
     
  • 3.18, Аноним (-), 02:39, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    путаешь мух с котлетами. К топику это отношения не имеет
     
  • 2.14, Аноним (-), 01:13, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Появился etag
     

  • 1.21, Аноним (-), 07:00, 08/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    чето я не догоняю спеки обновили а версия таже? Ребята хотят устроить вакханалию?
     
     
  • 2.24, кеипкп (?), 08:58, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > чето я не догоняю спеки обновили а версия таже? Ребята хотят устроить
    > вакханалию?

    1.1. получается, еще в стадии разработки и тестирования :)

     
     
  • 3.25, Аноним (-), 10:24, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ага 15 лет разрабатывают
     

  • 1.26, solardiz (ok), 12:40, 08/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Явно определено поведение при наличии непредусмотренных символов пробела и запрещено разбиение содержимого заголовков на несколько строк, что должно исключить появление уязвимостей, манипулирующих разделением запроса

    Это почему? Они действительно отказались от поддержки многострочных заголовков, но от атак разделением запроса это не поможет. Там есть секция про эти атаки, из которой нет ссылки на упомянутый в том же RFC отказ от многострочных заголовков. Насколько я понимаю, это две разные вещи, которые и сами авторы RFC не пытаются связать вместе. Или я не прочел нужное место (читал выборочно, так что вполне мог упустить)?

    http://tools.ietf.org/html/rfc7230#section-9.4
    http://tools.ietf.org/html/rfc7230#appendix-A.2

    Вот что еще интересно:

    "Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues"

    http://tools.ietf.org/html/rfc7230#section-2.7.1

    "A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value.  Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks."

     
     
  • 2.29, solardiz (ok), 15:27, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нашел упоминание здесь:

    https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

    "For example, folding a header across multiple lines is now deprecated, and the message parsing rules have been tightened up considerably to avoid attacks like HTTP response splitting."

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

     

  • 1.30, Аноним (-), 16:08, 08/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это они в честь проекта Xanadu обновились? :)
     
  • 1.34, Crazy Alex (ok), 03:06, 09/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот интересно, что что PUT обидели? Что плохого в запросе "обнови такой-то диапазон"? По нынешней логике получается, что правильно только целиком новую версию передавать? Или я чего-то не понимаю?
     
     
  • 2.35, ZZZ (??), 09:57, 09/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Есть PATCH.
     

  • 1.39, Аноним (-), 17:31, 10/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Стандартизован заголовок Forwarded для сохранения IP-адреса оригинального запроса после проброса соединения через прокси или балансировщик нагрузки. Forwarded пришёл на замену таким заголовкам, как X-Forwarded-For и X-Forwarded-Proto;

    Теперь, анон, если захочешь через проксю, то бан легче получишь?.

     
  • 1.42, Alexey (??), 13:24, 29/09/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Коллеги, явно пора ввести блок 600. Например,

    601: This site has been blocked by order of the government of Russia.

     
     
  • 2.43, Никита Ветров (?), 03:45, 03/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще для этого служит код 459
     

  • 1.44, Kodir (ok), 16:12, 01/01/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ...и запрещено разбиение содержимого заголовков на несколько строк

    Спросите лучше, какой кретин это придумал! Что вообще за блажь такая - лезть туда, где работает компьютер? Это ОН читает заголовки, ему пофиг одна там строка или две. А отлаживать - вообще по-барабану, сколько там строк - ОДНОЙ строкой можно спокойно передавать любые заголовки, они всё равно на экране врапятся.
    Ну и как после этого доверять документам тех, кто сами изначально ничего не могли продумать? Где гарантия, что залатанное одеяло - не та же трухлявая фигня?

     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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