Инженерный комитет IETF (Internet Engineering Task Force), занимающегося развитием протоколов и архитектуры сети Интернет, признал (https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead) устаревшим выпущенный в 1999 году RFC 2616 (http://tools.ietf.org/html/rfc2616), определяющий протокол HTTP/1.1. Аналогичная судьба постигла RFC 2617 (http://tools.ietf.org/html/rfc2617), определяющий механизмы аутентификации HTTP. Для описания HTTP/1.1 представлена (http://evertpot.com/http-11-updated/) серия новых RFC, учитывающих современные реалии:- RFC 7230: Message Syntax and Routing (http://tools.ietf.org/html/rfc7230)
- RFC 7231: Semantics and Content (http://tools.ietf.org/html/rfc7231)
- RFC 7232: Conditional Requests (http://tools.ietf.org/html/rfc7232)
- RFC 7233: Range Request (http://tools.ietf.org/html/rfc7233)
- RFC 7234: Caching (http://tools.ietf.org/html/rfc7234)
- RFC 7235: Authentication (http://tools.ietf.org/html/rfc7235)
- RFC 7236: Authentication Scheme Registrations (http://tools.ietf.org/html/rfc7236)
- RFC 7237: Method Registrations (http://tools.ietf.org/html/rfc7237)
- RFC 7238: the 308 status code (http://tools.ietf.org/html/rfc7238)
- RFC 7239: Forwarded HTTP extension (http://tools.ietf.org/html/rfc7239)
На подготовку обновления спецификации HTTP/1.1 ушло семь лет. Обновления были разработаны участниками группы 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://en.wikipedia.org/wiki/HTTP_response_splitting);
- Снято ограничение на два одновременных соединения к серверу;
- Прекращена поддержка HTTP/0.9;
- Удалено требование к использованию ISO-8859-1 как кодировки по умолчанию;
- Снято требование по обязательной обработке всех полей заголовков Content-*;
- Запрещено использование Content-Range в PUT-запросах;
- В качестве значения Referer при открытии страницы с нуля рекомендовано использовать "about:blank", что позволит отделить запросы без перехода от запросов с запрещённым Referer;
- Определена допустимость кэширования для кодов 204, 404, 405, 414 и 501;- Содержимое заголовка Location теперь может задаваться относительно текущего URI;
- Удалена поддержка заголовка Content-MD5.
URL: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
Новость: http://www.opennet.me/opennews/art.shtml?num=39956
А где код 451, актуальный и злободневный?
Хорошие люди попросили не делать.
Зачем попусту народ беспокоить. Пустое это.
А я чего-то сразу про 418 вспомнил
> Удалено требование к использованию ISO-8859-1 как кодировки по умолчаниюА было такое требование? Ну, знаете.
15 лет назад это казалось круто.
ура! дожил!
о елки.
ни хтмл5 и выше - стандартом не стали, ни вебсокеты :(
но за что спасибо - выпилили 0.9 хоть, вместе с 8859-1, музейные/багучие.
> о елки.
> ни хтмл5 и выше - стандартом не стали, ни вебсокеты :(Причем HTML к стандартизации HTTP?
а чем им Content-MD5 не угодил ? АНБ? :=/
Фича оказалась беполезной. Плюс на сегодня, MD5 в чистом виде использовать опасно/не рекомендуется.
путаешь мух с котлетами. К топику это отношения не имеет
Появился etag
чето я не догоняю спеки обновили а версия таже? Ребята хотят устроить вакханалию?
> чето я не догоняю спеки обновили а версия таже? Ребята хотят устроить
> вакханалию?1.1. получается, еще в стадии разработки и тестирования :)
ага 15 лет разрабатывают
> Явно определено поведение при наличии непредусмотренных символов пробела и запрещено разбиение содержимого заголовков на несколько строк, что должно исключить появление уязвимостей, манипулирующих разделением запросаЭто почему? Они действительно отказались от поддержки многострочных заголовков, но от атак разделением запроса это не поможет. Там есть секция про эти атаки, из которой нет ссылки на упомянутый в том же 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."
Нашел упоминание здесь: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."
Думаю, отказ от многострочных заголовков сам по себе не поможет, а вот сочетание ограничений может в отдельных случаях сделать атаки невозможными.
Это они в честь проекта Xanadu обновились? :)
Вот интересно, что что PUT обидели? Что плохого в запросе "обнови такой-то диапазон"? По нынешней логике получается, что правильно только целиком новую версию передавать? Или я чего-то не понимаю?
Есть PATCH.
>Стандартизован заголовок Forwarded для сохранения IP-адреса оригинального запроса после проброса соединения через прокси или балансировщик нагрузки. Forwarded пришёл на замену таким заголовкам, как X-Forwarded-For и X-Forwarded-Proto;Теперь, анон, если захочешь через проксю, то бан легче получишь?.
Коллеги, явно пора ввести блок 600. Например,601: This site has been blocked by order of the government of Russia.
Вообще для этого служит код 459
> ...и запрещено разбиение содержимого заголовков на несколько строкСпросите лучше, какой кретин это придумал! Что вообще за блажь такая - лезть туда, где работает компьютер? Это ОН читает заголовки, ему пофиг одна там строка или две. А отлаживать - вообще по-барабану, сколько там строк - ОДНОЙ строкой можно спокойно передавать любые заголовки, они всё равно на экране врапятся.
Ну и как после этого доверять документам тех, кто сами изначально ничего не могли продумать? Где гарантия, что залатанное одеяло - не та же трухлявая фигня?