Базовая схема идентификации (Authentication)

Базовая схема авторизации основана на модели, в которой агент пользователя должен идентифицировать себя с помощью имени пользователя и пароля, необходимого для каждой области ( realm ). Значение атрибута realm должно рассматриваться в виде неотображаемой строки символов, которая может сравниваться с другим значение realm на этом сервере.

Сервер обслужит запрос только в случае, если убедится в корректности имени и пароля пользователя для данной зоны защиты Request-URI. Не существует каких­-либо опционных параметров авторизации.

При получении неавторизованного запроса для URI в пределах зоны защиты (protection space) сервер может реагировать посылкой требования в виде:

WWW-Authenticate: Basic realm="WallyWorld"

где WallyWorld — строка, присвоенная сервером для идентификации зоны защиты Request-URI.

Чтобы получить авторизацию, клиент посылает свое имя и пароль, разделенные символом двоеточие (:) и закодированные согласно base64.

basiccredentials = "Basic" SP basiccookie basiccookie = userpass = userid : password userid = * password = *TEXT

Идентификационная информация может быть чувствительной к применению строчных или прописных букв.

Если агент пользователя хочет послать имя пользователя "Aladdin" и пароль "open sesame", он использует следующее поле заголовка:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Краткое изложение схемы авторизации

Краткое изложение идей авторизации для HTTP представлено в документе RFC-2069 [7.32].

Согласование содержимого

Большинство HTTP откликов включают в себя объекты, которые содержат информацию для интерпретации человеком­пользователем. Естественно, желательно обеспечить пользователя наилучшим объектом, соответствующим запросу. К сожалению, для серверов и кэшей не все пользователи имеют одни и те же предпочтения и не все агенты пользователя в равной степени способны обрабатывать все типы объектов. По этой причине HTTP имеет несколько механизмов обеспечения согласования содержимого — процесс выбора наилучшего представления для данного отклика, когда доступны несколько возможностей.

Замечание. Это не называется согласованием формата, потому что альтернативные представления могут принадлежать к одному и тому же типу среды, но использовать различные возможности этого типа, например, различные иностранные языки.

Любой отклик, содержащий тело объекта, может быть предметом согласования, включая отклики об ошибках. Существует два вида согласования содержимого, которые возможны в HTTP: под управлением сервера и под управлением агента пользователя. Эти два сорта согласования могут использоваться отдельно или в сочетании. Один из методов, называемый прозрачным согласованием, реализуется, когда кэш использует информацию, полученную от исходного сервера в результате согласования под управлением агента пользователя. Эта информация применяется для последующих запросов, где осуществляется согласование под управлением сервера.

О втором методе мы поговорим более подробно.

Согласование, управляемое сервером

Если выбор наилучшего представления для отклика выполнен с использованием некоторого алгоритма на сервере, такая процедура называется согласованием под управлением сервера. Выбор базируется на доступных представлениях отклика (размеры, в пределах которых он может варьироваться, язык, кодировка и т.д.) и на содержимом конкретных полей заголовка в сообщении­запросе или другой информации, имеющей отношение к запросу (например, сетевой адрес клиента).

Согласование, управляемое сервером, предпочтительнее, когда алгоритм выбора из числа доступных представлений трудно описать агенту пользователя. Согласование под управлением сервера привлекательно тогда, когда сервер хочет послать свои наилучшие предложения клиенту вместе с первым откликом (надеясь избежать задержек RTT последующих запросов — вдруг именно это предложение удовлетворит пользователя). Чтобы улучшить предложения сервера, агент пользователя может включить в запрос поля заголовка ( Accept, AcceptLanguage, AcceptEncoding и т.д.), которые описывают его предпочтения для данного запроса. Согласование под управлением сервера имеет следующие недостатки.

1. Серверу трудно определить, что является лучшим для любого заданного пользователя, так как это потребовало бы полного знания как возможностей агента пользователя, так конкретного назначения отклика (например, хочет ли пользователь видеть отклик на экране или отпечатать на принтере).

2. Заставлять агента пользователя описывать свои возможности при каждом запросе крайне неэффективно (ведь лишь небольшой процент запросов имеют несколько вариантов представления) и потенциально нарушает конфиденциальность пользователя.

3. Такое согласование усложняет реализацию исходного сервера и алгоритм генерации откликов на запросы.

4. Оно может ограничить возможность общедоступного кэша использовать один и тот же отклик для запросов многих пользователей.

HTTP/1.1 включает в себя следующие поля заголовка запроса для активации согласования, управляемого сервером, через описание возможностей агента пользователя и предпочтений самого пользователя: Accept, AcceptCharset, AcceptEncoding, AcceptLanguage и User-Agent. Однако исходный сервер не ограничен этими рамками и может варьировать отклик, основываясь на свойствах запроса, включая информацию помимо полей заголовка запроса или используя расширения полей заголовка нерассмотренные в данной спецификации.

Протокол HTTP/1.1 предусматривает следующие поля заголовка запроса, активизирующие согласование, управляемое сервером, и описывающие возможности агента пользоватеря и предпочтения клиента: Accept, AcceptCharset, AcceptEncoding, AcceptLanguage и User-Agent. Поле Vary может использоваться для описания пределов, в которых может варьироваться отклик (то есть, пределы, в которых исходный сервер выбирает свои наилучшие предложения отклика из многообразия представлений).