Кодирование

Когда данные передаются от клиента CGI-программе на сервере с использованием стандартного типа содержимого, закодированного как application/x-www-form, то некоторые "специальные" символы кодируются. Ниже представлены чаще всего кодируемые символы:

Все символы, чей ASCII-код меньше 32, кодируются как %XY, где XY — шестна-дцатеричный код.

Символ пробела кодируется либо как +, либо как 120.

Символ двойной кавычки (") кодируется как %22.

Символ одинарной кавычки (‘), который кодируется как %27.

Символ /, который кодируется как %2F.

Безопасность и авторизация

Стандартный механизм заголовков HTTP также представляет ядро стандартного механизма безопасности HTTP. Безопасная транзакция документа происходит следующим образом:

Клиент (браузер) запрашивает документ, используя стандартный метод GET. В этот момент клиент не знает о том, что документ защищен средствами безопасности.

Доступ к документу запрещается с выдачей заголовка 301. Наряду с заголовком 401 сервер посылает требуемый метод авторизации, который должен быть использован клиентом в ответ (заголовок WWW-Authenticate).

Браузер отвечает на заголовок 301, отображая диалоговое окно с запросом имени и пароля пользователя.

Пользователь вводит имя и пароль и отправляет их. Браузер передает их серверу вместе с заголовком авторизации.

Если доступ разрешен, запрошенный документ отправляется браузеру. Если же в доступе отказано, пользователь вновь получает диалоговое окно с запросом параметров авторизации и заполняет его.

Существует множество схем авторизации в HTTP. Наиболее часто используется только одна из них — называемая Basic-аутентификацией. По этой схеме заголовок авторизации имеет следующую форму:

Authorization: SCHEME REALM

Слово SCHEME может быть заменено на BASIC, а слово REALM — на закодированную форму данных авторизации (имени и пароля).

Это формат закодированного значения "имя:пароль" с использованием алгоритма Ьа$е64. Предположим, что ваше имя — sjohnson, а пароль — duckduckgoose. Применение кодирующего алгоритма base64 к ним даст нам такой заголовок авторизации:

Authorization: Basic c2pvaG5zb246ZHVja2RlY2tnb29zZQ==

Помимо Basic-аутентификации HTTP также применяется аутентификация Digest. Несмотря на то что базовая аутентификация HTTP "закодирована", она в действи-тельности не является безопасной, поскольку информация передается в открытом виде (кодирование маскирует, но реально не скрывает имя и пароль пользователя). Хотя аутентификация Digest технически более защищена, многие Web-браузеры не поддерживают ее.

Помимо традиционной защиты на базе HTTP, которая реализована на уровне Web-сервера, безопасность уровня приложений реализуется разработчиками приложений. Этот подход обычно использует cookie-наборы для сохранения идентификации пользователя. Ключевой выгодой отказа от применения HTTP-защиты является то, что это дает возможность разработчику полностью контролировать вид и поведение формы регистрации пользователя.

Кэширование содержимого http на стороне клиента

Когда информация передается клиенту через Internet, то клиент - браузер может локально кэшировать ее. С учетом того, что большая часть содержимого Internet, если не все, изменяется относительно редко в контексте отдельного пользовательского сеанса, кэширование становится незаменимым средством повышения производительности.

Единственное требование, связанное с кэшированием, очень простое: необходимо уведомление об изменениях. Почти каждый Web-разработчик сталкивался с ситуацией, когда он изменяет информацию на Web-сервере, но при обновлении ее в браузере в нем остается старое содержимое. Это — пример классической проблемы кэширования. К решению упомянутой проблемы существуют два стандартных подхода, включающих использование HTTP-заголовков. Первый метод проверяет наиболее свежие модификации по временной метке документа, в то время как второй метод проверяет изменения в дескрипторе сущности (Emily tag — E-Tag), ассоциированном с запрашиваемым ресурсом.

Кэширование также может управляться или модифицироваться с помощью HTTP-заголовков Cache-Control и Pragma. Обычно они применяются в ситуациях, когда вы хотите указать, что определенный документ не должен кэшнроваться на клиенте. За¬головок Pragma используется, начиная с версии HTTP 1.0, и сопровождается значени¬ем No-cache для выключения кэширования, как показано ниже:

Pragma: No-cache

Если вы используете HTTP 1.1, то захотите применять заголовок Cache-Contrr 1, который заменил Pragma. Ниже показан эквивалент предыдущего выражения Pragma:

Cache-Control: No-cache

Классическое кэширование HTTP 1.0 управлялось с применением заголовка If-Modif ied-Since в запросе GET. При таком подходе клиент сообщал серверу, что он должен присылать данные для указанного URL, только если они были модифицированы после момента времени, переданного в заголовке. Если документ не модифицировался, посылался код состояния 304 (Not Modified).

Кроме заголовка If-Modified-Since существует также заголовок If-Unmodified-Since. Этот заголовок указывает серверу, что присылать данные нужно, только если они не изменялись после указанной даты.

В HTTP 1.1 был предложен новый подход к управлению кэшированием - E-Tag. Е-Таg — это уникальный идентификатор, ассоциированный с определенным документом и вычисляемый на основе его содержимого. Фактически хеширование MD5 - это один из способов вычисления E-Tag документа. Идея заключается в том, что если документ изменился, то его E-Tag также изменился. Это упрощает проверку — нужно сверять только значение E-Tag, а не URL вместе с датой модификации. К тому же, если вы работаете с динамическими документами, им часто недостает даты последней модификации, что дает еще один аргумент в пользу применения E-Tag для управления кэшированием.

Если вы программируете на РНР, то должны использовать функцию header(), чтобы отправит соответствующий E-Tag, как показано в примере:

<?php

$etag = md5($content);

header("ETag: $etag");

?>