Инженерный комитет 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.dev/opennews/art.shtml?num=39956
Вариант для распечатки
(??) on 29-Сен-14, 13:24 
