Программы
Быстрее! Проще! Нагляднее!

Быстрее! Проще! Нагляднее!

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 версия протокола не может их удовлетворить…

Также может быть вам интересно:

Вначале было слово… Потом – протокол для его передачи

Во-первых, здесь предлагается решение проблемы доступа к информации в CERN. Во-вторых, оно вносит идею связанных информационных систем и сравнивает их с менее гибкими способами поиска информации.

Читать »

7-ой день сотворения

Читать »
Фото Python: Встроенные типы данных (list, set, dict, etc)

Python: Встроенные типы данных (list, set, dict, etc)

В Python есть множество встроенных типов данных. Их использование значительно упрощает жизнь и ускоряет разработку программных продуктов.

Фото Python: типы данных, переменные, логическое ветвление и циклы

Python: типы данных, переменные, логическое ветвление и циклы

Первая часть заметок о Python. О базовых типах, переменных, ветвлении и циклах.

Фото Как сделать свою middleware в Django (с примерами)

Как сделать свою middleware в Django (с примерами)

Middleware или "промежуточное программное обеспечение" - элегантный способ установить общие правила обработки запросов и ответов приложения. Давайте напишем парочку middleware, чтобы понять, как они работают.

Фото Как настроить отправку почты из Django

Как настроить отправку почты из Django

Письма об ошибках, отчёты на почту, восстановление паролей - всё это полезно при работе с сайтом. Django предоставляет удобный способ это сделать с минимумом настроек!

Фото Добавляем постраничную пагинацию на Django сайт

Добавляем постраничную пагинацию на Django сайт

На сайтах часто встречаются многостраничные объекты: список товаров, список заметок и т.д. Поэтому важно уметь добавить навигацию по страницам на Django-проекте.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если одни и те же данные нужны в разных местах, лучше сделать свой контекст-процессор.

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать свои команды для управления проектом.

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система прав доступа для пользователей - давайте её рассмотрим!