Поле Warning (Предупреждение)

Поле заголовка отклика Warning используется для переноса дополнительной информации о состоянии отклика, которая может отражать статусный код. Эта информация обычно служит для предупреждения о возможной потере семантической прозрачности изза операций кэширования. Заголовки Warning посылаются с откликами, применяя:

Warning = "Warning" ":" 1#warningvalue
warningvalue = warncode SP warnagent SP warntext
warncode = 2DIGIT
warnagent = (host [ ":" port ]) | pseudonym
; имя или псевдоним сервера, добавившего заголовок Warning,
; предназначенный для целей отладки
warntext = quotedstring

Отклик может нести в себе более одного заголовка Warning.

Запись warntext производится на естественном языке и с применением символьного набора, приемлемого для принимающего отклик лица. Это решение может базироваться на некоей имеющейся информации, такой, как положение кэша или пользователя, поле запроса AcceptLanguage, поле отклика ContentLanguage и т.д. Языком по умолчанию является английский, а символьным набором — ISO88591.

Если используется символьный набор, отличный от ISO88591, он должен быть закодирован в warntext с использованием метода, описанного в RFC-1522 [7.14].

Любой сервер или кэш может добавить заголовки Warning к отклику. Новые заголовки Warning должны добавляться после любых существующих заголовков Warning. Кэш не должен уничтожать какие-­либо заголовки, которые он получил в отклике. Однако если кэш успешно перепроверил запись, ему следует удалить все заголовки Warning, присоединенные ранее, за исключением специальных кодов Warning. Он должен добавить к записи новые заголовки Warning, полученные с откликом перепроверки. Другими словами, заголовками Warning являются те, которые были бы получены в отклике на запрос в данный момент.

Когда к отклику подключено несколько заголовков Warning, агенту пользователя следует отображать их столько, сколько возможно, для того чтобы они появились в отклике. Если невозможно отобразить все предупреждения, агент пользователя должен следовать следующим эвристическим правилам.

Предупреждения, которые появляются в отклике раньше, имеют приоритет перед теми, что появляются позже.

Предупреждения с предпочитаемым пользователем символьным набором имеют приоритет перед предупреждениями с другими, но идентичными warncodes и warnagents наборами.

Системы, которые генерируют несколько заголовков Warning, должны упорядочить их с учетом ожидаемого поведения агента пользователя.

Далее представлен список определенных в настоящее время кодов предупреждений, каждый из которых сопровождается рекомендуемым текстом на английском языке и описанием его значения.

10 Response is stale (отклик устарел)

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

11 Revalidation failed (перепроверка пригодности неудачна)

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

12 Disconnected operation (работа в отключенном от сети состоянии)

Следует включать, если кэш намерено отключен от остальной сети на определенный период времени.

13 Heuristic expiration (эвристическое определение времени пригодности)

Должно включаться, если кэш эвристически выбрал время жизни больше 24 часов, а возраст отклика превышает эту величину.

14 Transformation applied (применено преобразование)

Должно добавляться промежуточным кэшем или прокси, если он использует какое­либо преобразование, изменяющее кодировку содержимого (как это специфицировано в заголовке Content-Encoding) или тип среды (как это описано в заголовке Content-Type) отклика, если только этот код предупреждения не присутствует уже в отклике.

99 Разные предупреждения

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

Поле WWW-Authenticate

Поле заголовка отклика WWW-Authenticate должно включаться в сообщения откликов со статусным кодом 401 (Unauthorized). Значение поля содержит, по крайней мере, одно требование, которое указывает на схему идентификации и на параметры, применимые для Request-URI.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

Агенты пользователя должны проявлять особую тщательность при разборе значения поля WWW-Authenticate, если оно содержит более одного требования или если прислано более чем одно поле заголовка WWW-Authenticate, так как содержимое требования может само содержать список параметров идентификации, элементы которого разделены запятыми.

Соображения безопасности

Этот раздел предназначен для того, чтобы проинформировать разработчиков приложений, поставщиков информации и пользователей об ограничениях безопасности в HTTP/1.1.

Аутентификация клиентов

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

Наиболее серьезным дефектом базового механизма идентификации в HTTP является то, что пароль пользователя передается по сети в незашифрованном виде.

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

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

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

Базовая идентификация уязвима также для атак поддельных серверов. Когда пользователь связывается с ЭВМ, которая содержит информацию, защищенную с использованием базовой системой идентификации, может оказаться, что в действительности он соединяется с серверомзлоумышленником, целью которого является получение идентификационных параметров пользователя (например, имени и пароля). Этот тип атак невозможен при использовании идентификации с помощью дайджестов [7.32]. Разработчики серверов должны учитывать возможности такого рода атак со стороны ложных серверов или CGIскриптов. В частности, очень опасно для сервера просто прерывать связь со шлюзом, так как этот шлюз может тогда использовать механизм постоянного соединения для выполнения нескольких процедур с клиентом, исполняя роль исходного сервера не заметно для клиента.