Кратко

  • RFC 2295 сделал видимыми через машиночитаемый список несколько представлений, связанных с одним HTTP URI, но ответ со списком не содержал данных ни одного варианта.
  • Выбор, получение и показ оставались разными этапами: при соблюдении условий сервер мог вернуть выбранное представление, а клиент — самостоятельно выбрать и запросить вариант из списка.

У ресурса могло быть несколько ответов

К концу 1990-х у Всемирной паутины уже возникла практическая задача: один ресурс мог существовать в HTML и PostScript, на английском и французском языках, а подходящая версия зависела от возможностей пользовательской программы. Издатель мог назначить отдельный URL каждой версии или организовать выбор за одним URI. Но требовалось не только выбрать вариант: посредники, особенно кэши, должны были понимать, какой ответ соответствует какому запросу.

RFC 2295 «Transparent Content Negotiation in HTTP» предложил экспериментальный механизм, который делал альтернативы видимыми. В документе от марта 1998 года каждая версия называлась вариантом, а её машиночитаемое описание привязывалось к списку вариантов согласуемого ресурса. Заголовок Alternates мог указывать URI каждого кандидата и такие свойства, как тип медиа, язык, качество источника и функции. Слово «прозрачный» означало, что варианты, находящиеся на исходном сервере, становились видимыми внешним участникам. Оно не означало, что все браузеры будут согласовывать автоматически или что сам выбор перестанет быть заметен.

Механизм задавал четыре измерения согласования: тип медиа, кодировку символов, язык и функции. Последнее измерение дополняло первые три свойствами, которые они не охватывали, например расширениями HTML или возможностями других форматов. Кодирование содержимого — к примеру, сжатие — было ортогональным и не считалось пятым измерением вариантов. Это важная граница: документ описывал, какое представление может подойти, а не все преобразования, которые сервер способен применить к его байтам.

Три подтверждения вместо одного события

Ответ со списком был каталогом. RFC 2295 определяет его как ответ, содержащий список вариантов, но не данные вариантов. Пользовательская программа с поддержкой прозрачного согласования могла оценить кандидатов и запросить один из них обычным HTTP-запросом по его URI. В примере RFC эти действия чётко разделены: сначала сервер возвращает список, затем клиент запрашивает paper.1, и лишь во втором ответе находится документ. Ответ 300 Multiple Choices тоже мог включать текст для ручного выбора — как для человека, так и для программы без поддержки согласования. Но и тогда список не становился выбранным представлением.

Сервер не был всего лишь каталогом. Ответ выбора (choice response) возвращал представление лучшего варианта и мог дополнительно включать список. Для этого серверу требовалось достаточно сведений, чтобы выбрать за пользовательскую программу, а сам вариант должен был удовлетворять заданному в RFC условию соседства URI. Сопутствующий экспериментальный RFC 2296 определил алгоритм удалённого выбора и сделал его результат условным: если нельзя установить положительный и однозначный лучший вариант либо не выполнено условие соседства, алгоритм возвращает список, а не выбранное представление. Клиент также мог применить собственный алгоритм и получить другой вариант, если список оставался доступен.

Поэтому описывать историю словами «выбирал клиент» было бы неверно. Иногда выбор мог сделать он, иногда — сервер. Протокол разделял перечень кандидатов, полномочие принять решение, ответ с данными и последующий показ. С точки зрения сервера заголовок Negotiate сообщал, что пользовательская программа заявляет о поддержке прозрачного согласования. Такое заявление о возможностях не доказывает, что конкретный запрос воспользовался механизмом.

Кэш был частью замысла

Согласование может привести к тому, что один URI отдаёт разные представления. Если кэш перепутает ответы, даже хороший алгоритм выбора даст плохой результат. Поэтому RFC 2295 опирался на Vary и теги сущностей HTTP, а также добавлял валидаторы списков вариантов. Документ описывал, как кэш может извлечь обычный HTTP-ответ из ответа выбора и как местоположение выбранного ресурса связано с согласуемым ресурсом. Корректность кэширования была не второстепенной деталью реализации, а частью контракта, позволявшего повторно использовать URI.

У замысла была и цена. Передача всех предпочтений в каждом запросе могла увеличивать заголовки, поэтому пользовательской программе часто приходилось анализировать список локально. Но предпочтения Accept способны раскрыть сведения о программном обеспечении или окружении человека. В документе прямо обсуждались утечка приватной информации, подмена ответов ресурсов-вариантов и уязвимости, которые может выявить согласование. Это зафиксированные проектные риски, а не подтверждение конкретного инцидента.

RFC 2295 прямо относит себя к категории Experimental и подчёркивает, что не устанавливает Интернет-стандарт. Прозрачное согласование применялось к GET и HEAD, а не ко всем HTTP-транзакциям. По спецификации можно восстановить замысел: сделать альтернативы доступными для проверки и распределить выбор между клиентами, серверами и кэшами. Однако изученные здесь источники не подтверждают опрос совместимости браузеров, масштаб внедрения или пользовательский результат. Объявленный вариант мог остаться незапрошенным, а полученный ответ не доказывает, что именно увидел человек.

Источники