HTTP/1.0
Однако, нового протокола долго не было. Аж до 1996-ого года. В мае состоялся выход RFC-1945 — документа, описывающего нововведения. Также была внесена некоторая ясность в терминологический аппарат: введены термины Uniform Resource Identifier (URI), URL (location) и URN (name).
По сравнению с 0.9-ым протоколом появились важные изменения:
- Введена поддержка кеширования, что снизило траффик и нагрузку на сервер.
- Появилась поддержка MIME, следовательно, теперь передать через HTTP можно всё.
- Для совместимости с предыдущим форматом и сервера, и клиенты должны уметь работать с обеими версиями протокола.
- Появилась возможность сжатия.
- Теперь, помимо строки запроса, можно было добавить заголовки: строка запроса, с новой строки заголовки, разделённые переносами строк. А в конце – двойной перенос строки.
- Ответ так же отправлялся теперь с заголовками.
- Появились новые методы запроса: POST и HEAD.
Итак, что же могла версия 1.0 по сравнению с 0.9?
Ну, во-первых, в ней мы ушли от дикого в наше время консольного интерфейса. А это позволяла уже программная база: появился графический Windows 95, для Unix-подобных систем уже давно существовала X Window System (для Linux так же была GNU-версия). Думаю, те, кому хоть раз приходилось заниматься веб-серфингом с помощью браузера Lynx, должны понять, насколько проще и приятнее стало пользоваться вебом.
Помимо этого, при указании сервером значения “application/octet-stream” в соответствующем поле заголовка сервер мог передавать не только в текстовом формате, но и в бинарном. Последнее новшество позволило передавать по HTTP ещё и картинки.
Одними улучшениями интерфейса Тим Бернерс-Ли не ограничился. Протокол HTTP является текстовым, что многократно увеличивает объём передаваемой информации. Чтобы уменьшить объем траффика, были введены следующие новшества:
- Возможность сжатия данных (например, gzip’ом)
- Поле запроса If-Modified-Since позволяло запросить документ у сервера (GET’ом) только в том случае, если документ был изменён со времени, указанного пользователем.
Ещё одним недостатком версии 0.9 был его GET. Точнее, сам GET не проблема – со своей задачей передачи запроса на документ серверу он отлично справлялся. Но задачи бывают разные, и GET, к примеру, не сможет передать серверу десяток килобайт данных (есть ограничение на длину строки запроса). Опять же передавать пароль в строке запроса – моветон. Именно для разрешения этих проблем был введён метод POST. Этот метод имел уже помимо заголовков, ещё и “тело” с данными, которые нужно было пересылать серверу. Теперь размер передаваемых данных ограничивался уже более внушительным числом (собственно столько, сколько указано в настройках сервера).
Также был добавлен служебный запрос HEAD. По своей сути он очень похож на GET, однако сервер отвечает на него только заголовками (тело ответа не отсылает). Таким запросом, к примеру, удобно проверять актуальность документа (If modify).
Ещё один важный момент, который не был реализован в 0.9-ом протоколе, однако заявлялся для исполнения работниками CERN, — защита данных. Реализация появилась в 1.0-ой версии через заголовки: у сервера был запрос “WWW-Authenticate”, на что клиент отвечал заголовком “Authorization”, передавая пару аккаунт-пароль (разделённые символом “:”), закодированные в base64.
О пользе эпиграфов заголовков
Пожалуй, самым революционным update’мо протокола было введение заголовков в отправляемые и присылаемые сообщения. Теперь документы не просто запрашивались, а запрашивались с учётом некоторой дополнительной информации, позволяющей создавать информацию для конкретного “состояния” клиента. Помимо возможности послать серверу спец. данные, была введена возможность и серверу отправить свою информацию на клиент. Сообщения могли быть напрямую не связаны (заголовок клиента, о языковых предпочтениях), а могли быть и парные: set-cookie, устанавливающий некоторое значение клиенту, и cookie, возвращающий это значение.
В частности, через механизм заголовков были реализованы большинство функций, описанных выше (if modify, аутентификация). Есть ещё несколько функций, облегчающих жизнь веба, поэтому, думаю их стоит упомянуть:
Заголовок expires задаётся сервером. В нём клиенту указывается “срок годности” полученной информации (время актуальности). Это позволяет серверу сообщить клиенту, что документ не может ещё считаться устаревшим даже без дополнительного запроса if-modify. Этот подход снижает нагрузку на сервер и канал, ведь до достижения срока годности браузер будет брать версию этого документа из кеша. Но по данному времени браузер должен перестать использовать кеш этого документа, что позволяет сохранять информацию актуальной.
Внимание! Истекание времени, указанного в заголовке expires не говорит о том, что документ изменился или же совсем исчез. И не даёт гарантию того, что он не изменится или удалиться до времени истечения данного срока. Это просто некоторая оценка времени “жизни” информации. А, как известно из курса статистики, оценка может сильно отличаться от реального значения случайной, по-сути, величины.
Думаю, значение заголовка pragma должно быть интуитивно понятно любому, кто использовал прагмы при написании perl-скриптов. Заголовок используется для работы со специальными параметрами (ограничительными, отключающими различные фичи). К примеру, с помощью прагмы no-cache, можно попросить самый актуальный вариант документа, а не копию n-ой давности, лежащую в кеше. Итого, мы отключаем возможность протокола HTTP (кеширование) для своих нужд.
Зачем печенье в интернете?
Изначально этот раздел я хотел назвать “о сотворении Богом утконоса”, но посчитал это название слишком пафосным. Однако, были ли у меня основания на это? Итак, речь пойдет о заголовке (инструменте) cookie.
Данная технология создаёт механизм установки сервером на клиенте некоего набора данных. В свою очередь, клиент будет отправлять эти данные на сервер, пока сервер не заменит их или же пока они не “протухнут” (на cookie устанавливается срок годности).
Кто же решил вменить серверу ещё и обязанности повара-кондитера? А главное — зачем? Напоминаю, что протокол HTTP рассматривает все обращения к серверу как независимые. И не поддерживает сессии (как это, к примеру, делает ssh) ещё с 0.9 ой версии, и, как выяснится позже, никогда не будет поддерживать. Но сам механизм авторизации пользователя на сервере нужен. Он позволяет персонифицировать подход к клиенту: хранить о нём данные. Все ваши учётки на различных форумах или мэйлах имеют возможность существовать только благодаря главному костылю протокола HTTP — cookie. Теперь понятно — зачем?
Справедливости ради отвечу и на первый вопрос: кто это придумал. Лу Монтулли в 1994ом году, работая в Netscape, столкнулся с некой ущербностью этого протокола и предложил решение – новый заголовок… И всего-то!
Вот насколько важным было введение заголовков. Теперь практически любое новшество, требующее дополнительную информацию от сервера или от клиента, могло быть реализовано в рамках старого протокола. Достаточно было клиенту и серверу договориться об одном небольшом изменении, а для этого нет нужды придумывать новую архитектуру и специальные возможности…
Гордый anonymous не ест бесплатное печенье!
Казалось бы, была решена архитектурная проблема протокола – нужно радоваться, но мудрый анонимус знал, что это всего лишь метка на всё и каждого… Многие пользователи интернет уверены, что куки лишают их анонимности. Казалось бы — блажь, ан нет! Замечали ли вы, что после поиска в yandex “поиск квартир в Екатеринбурге”, вам навязчиво рекламируют “Агентства недвижимости Москвы”. Как же продавцы рекламы узнают о наших предпочтениях? Очень просто. Достаточно “посчитать” ваш поиск, записать его напротив вашего же куки… А потом просто сопоставлять.
А замечали ли вы, что по обращению вами на ваш уютный (пусть здесь каждый напишет своё), вас ещё соединяют с неким ajax.googleapis.com? А я вот замечал, подключаясь к linux.org.ru… Благо траффик медленный. Это ничто иное, как центр аналитики google, собирающий информацию о вас. Замечали ли вы, что со временем результаты поиска становились более адекватными? Я — нет. Бред как выводился, так и выводится… А информация собирается… Думаем, товарищи, думаем!
Что же делает умный анонимус в такой ситуации? Берётся за оружие, уходит в подполье!
Теперь протокол уже выглядит солиднее. По сравнению с 0.9 было добавлено огромное число расширений. Однако, Тим Бернерс-Ли понимал, что за один день провести переход с 0.9 на 1.0 не удастся, поэтому всё ПО 1.0 должно было поддерживать и предыдущую версию протокола. К сожалению, нынешним протоколо-строителям этого понимания не хватает (вспоминается свистопляска AOL во время смены протокола ICQ).
Что ж, по такому протоколу приятно работать… Чего ещё желать? Но прогресс не стоит на месте. Мир меняется, появляются всё новые и новые потребности. Вот уже и 1.0 версия протокола не может их удовлетворить…