История развития НТТР/1.0

С япваря 1995 г. по июнь 1999 г. HTTP Working Group прилагала значительные усилия для решения проблем, связанных с НТТР/1.0. За четыре с лишпим года эволюции от НТТР/1.0 до НТТР/1.1 вышло несколько версий документов для этого протокола. Дискуссии в HTTP Working Group за этот период достунны в онлайновом архиве [WG-99j. Некоторые из основных изменений протокола, сделап- пые в результате этих дискуссий, обсуждаются в статье [KMK99]. Движущей силой развития протокола было влияние, оказанное НТТР/1.0 на Internet на начальном этапе, и желапие реализовать новые возможности, основываясь на опыте разработчиков различных \УеЬ-компонентов. Взрыв популярности Web пришелся именно на этот период.

Переход от НТТР/1.0 к НТТР/1.1 не был пи гладким, пи простым. Некоторые разработчики браузеров и серверов включали в свои продукты возможности, которые не соответствовали общепринятой практике применения HTTP 1.0, по пим не было достигнуто согласия в процессе дискуссий в HTTP Working Group. Как только новые возможности становились частью повседпевпой практики, на повестке дпя в Working Group вставал вопрос об обратной совместимости. Источником многих известных проблем с НТТР/1.1 являлось как раз обеспечение обратной совместимости и ограпиченные возможности расширения НТТР/1.0. Тем не менее, протокол все же проделал значительный путь эволюции, на котором было разрешено большое число проблем.

Мпогие браузеры и прокси-серверы остаются по-прежпему несовместимыми с НТТР/1.1. На группу разработки стандарта HTTP оказывалось значительное давление, связанное с коммерческими интересами, а не с техническими вопросами.

Несколько известных компаний являлись владельцами популярных продуктов. Корпорации, которые были заинтересованы в сохранении определенных возможностей или в продвижении своего подхода, открыто заявляли о своих особых интересах. И все же процесс совершенствования протокола был завершен таким образом, что ни одпа из частных компаний не смогла навязать свою особую точку зрепия всему Web-сообществу. Даже в тех случаях, когда большая часть рынка принадлежит одиому продукту, окончательная версия протокола не выглядит попавшей под влияние решений, реализованных в этом продукте. Одной из причин этого является процедура работы пад протоколами в IETF, в основе которой лежит достижение общего согласия. Другая причина — это усилия HTTP Working Group. Однако существующие реализации оказывали влияние на введение некоторых новых возможностей. Одним из примеров является возможность осуществлять запросы на диапазоны данных, что будет рассмотрено в разделе 7.4.1. Существующие реализации оказали также существенное влияние на проблему управления состоянием в HTTP [KM00J.

Попытки стандартизации или модернизации любого протокола проходят через ряд последовательных этапов; детальпое описание этого процесса представлено в RFC 2026 [Bra96b].

1.       Проект документа (Internet Draft) готовится и затем обсуждается с использованием электронных средств информации и на совещаниях, проводимых IETF три раза в год. Проект документа публикуется в электронном виде на Web-сайте IETF.

2.       Исполнительный комитет IETF (IESG — Internet Engineering Steering Group) может отнести проект документа к одной из трех категорий: информационной, экспериментальной или стандартам. Если IESG одобряет проект документа, то последний становится официальным документом RFC (Request For Comment) и ему присваивается номер. Информационный документ не должен рассматриваться пи в качестве руководства при реализации, пи в качестве стандарта. Например, документ RFC 1945, в котором описана структура НТТР/1.0, относится к категории информационных документов. Аналогичным образом, спецификация нового протокола Internet Printing Protocol (IPP), описанная в RFC 2565 [HBMT99J, отпосигся к категории экспериментальных документов, а не стандарта. Обычно процесс стандарт изации требует нескольких версий проекта документа.

3.       Проект документа в процессе разработки стандарта проходит через три этапа: предложение по стандарту (Proposed Standard), проект стандарта (Draft Standard) и стандарт Internet (Internet Standard). Предложение по стандарту — это первая ступенька на пути к спецификации протокола, предложение должно иметь ясную структуру, апробированную сообществом, но пи реализация, ни практическое применение не являются на этом этапе обязательными. Проект стандарта должен иметь как минимум две совместимые между собой реализации, разработанные независимо друг от друга. Эти реализации должны включать в себя различные возможности спецификации с тем, чтобы только зрелые и стабильные возможности спецификации достигли уровня проекта стандарта. Наконец, спецификация достигает статуса стандарта Internet после продолжительного тестирования и общего призпапия полезности этой спецификации для Internet-сообщества. Такой спецификации присваивается и помер RFC, и помер в отделыюй серии документов, называемых STD (сокращение от Standard). На каждом этапе стандартизации отводится некоторое время на получение отзывов и комментариев от Internet-coo6mecr- ва. Предложение по стандарту должно минимум шесть месяцев оставаться на данной стадии, прежде чем осуществляется переход на уровень проекта стандарта, хотя этот период может продолжаться значительно дольше. На уровне проекта стандарта документ должен находиться четыре месяца или, по меньшей мере, до следующего заседания IETF (независимо от срока), прежде чем Можно будет перейти к этапу стандарта Internet.

Процесс эволюции протокола HTTP был осложнен появлением промежуточного документа — предложения по стандарту RFC 2068 [FGM+97|, в котором было зафиксировано состояние дискуссий по НТТР/1.1 на то время. К сожалению, документ, представленный на рассмотрение в качестве предложения по стандарту НТТР/1.1, обсуждался дольше, чем обычно, и был принят в качестве предложения по стандарту только в январе 1997 г. Частично из-за неудачного стечения обстоятельств, появление большинства новых версий браузеров совпало по времени с появлением RFC 2068. Вскоре некоторые реализации клиентов и серверов в общем и целом совместимые со спецификацией, описанной в RFC 2068, стали претендовать на то, чтобы считаться совместимыми НТТР/1.1, хотя спецификация протокола НТТР/1.1 была всего лишь на этане предложения по стандарту, а не стандарта Internet. Этот помер версии быстро стал притчей во языцех, поскольку Web-серверы претендовали на то, что они реализуют «стандарт» НТТР/1.1, который в то время не существовал (и не существует на момент публикации этой статьи). Таким образом, хотя спецификация вскрыла существующие проблемы (и зафиксировала их в разделе 19.6.3 RFC 2616), программное обеспечение, реализующее спецификацию, изменялось не так быстро. Тем не менее, появление RFC 2068 послужило поводом для тестирования различных программных компонентов, реализующих спецификацию.

Таким образом, усилия но стандартизации протокола НТТР/1.1 усугублялись дополнительными проблемами, связанными с обеспечением совместимости с браузерами и серверами, реализующими RFC 2068. Проект стандарта RFC 2616 [FGM’99J вышел в июпе 1999 г. Предполагалось, что этот проект станет официальным стандартом Internet в 2001. Одпа из причин задержки заключается в том, что стандарт IETF не может быть оформлен официально до тех пор, пока из него не будут удалены «11епормативпые» ссылки. В случае с НТТР/1.1 это ссылка на MIME E-mail Encapsulation (MHTML, RFC 2110 [PH97J), документ который впоследствии был заменеп документом RFC 2557 [PH99J.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100