[apache-rus] Vary (кажись, в самое время :)

[Alex Tutubalin <lexa@lexa.ru>]

Hi,

 AT>> Ничего не понял :). Директива никуда не выдается, r->pool у нас вроде
 AT>> общий на всех. Поясните простыми словами.
 alr> Выдаётся поле Vary. Если его кто-не не сформировал раньше.
У кого-то из нас проблемы с русским языком. То-ли я переутомился на ниве 
перестановки мебели в квартире, то-ли Вы как-то не так пишете.

Вашу фразу я (буквально) понял так: "Поле Vary:
/,если его кто-то не сформировал раньше,/ выдается Russian Apache даже при 
CharsetDisableAcceptCharset On"  А если его кто-то сформировал, то не
выдается ?

Я только-что потренировался на apache.lexa.ru:8100.
Если включить CharsetDisableAcceptCharset, то Vary: accept-charset
НЕ ВЫДАЕТСЯ модулем mod_charset (я это уже выключил обратно и Vary опять есть).
Что я собственно и пытался сказать.

Естественно, если какой-то модуль счел нужным его поставить, то Vary выдаваться 
будет. Под рукой нет исходников, но скорее всего этот модуль называется 
mod_negotiation с Options MultiViews :)

 AT>> А свою мысль повторю. Сервер не выдает заголовок Vary: если в данном
 AT>> "измерении" нет variations. Т.е. чтобы избавиться от Vary: нужно
 AT>> выключить для данного URL все  не-URL-encoded методы распознавания
 AT>> клиентского charset.
 alr> В том-то и дело, что это _не_ так. А я изначально и просил именно такого
 alr> поведения. (см. ниже)
Какая у вас версия Russian Apache ? В моей (1.3.6 pl28.15) все именно так как я 
пишу. И неудивительно - я сам этот код и написал.

 alr> Так о том и идёт речь всё время - _если_ прошёл Redirect по порту или мы
 alr> _изначально_ пришли по порту, а порт стоит на максимальном приоритете, то
 alr> Vary выдавать не надо. А она выдаётся. Именно об этом и идёт (шёл) наш
 alr> разговор с самого начала. Ну _нету_ вариантности в ситуации прихода по
 alr> порту. Можно было бы ещё обсуждать "возможную вариантность" если клиент
 alr> выдал Accept-charset, но при его отсутствии уж точно нету.
Давайте рассмотрим сначала пример с Accept-Language и включенным MultiViews.
Принципиально он ничем не отличается от Accept-Charset, разница лишь в том, что 
большинство броузеров ставят хоть какой-то Accept-Language и пример будет
более ярким.

Пусть все ходят через прокси-кэш по протоколу HTTP/1.1, а сервер знает все
языки.
Если не выдавать Vary, то первый клиент (скажем, с Accept-Language: zh)
вытянет через прокси какой-то документ (в китайском варианте), который залипнет 
в кэше. После чего второй клиент (Accept-Language: cz) сможет получить чешский 
вариант только нажав Shift-Reload в своем броузере (если он это умеет делать, 
обычные пользователи об этой фиче не знают). Без этого он будет получать
(из кэша) китайский вариант.

Предположим, первым клиентом была какая-нибудь Altavista или CoolSearch,
который не поставил Accept-Language, но пришел через тот же кэш. Сервер выдаст 
ему документ в соответствии с DefaultLanguage (например, cr), который залипнет 
в том же кэше. После чего все клиенты кэша начнут получать корейский вариант.


Теперь вернемся к ситуации с Accept-Charset. Она ничем не отличается от 
Accept-Language, за тем исключением, что тот Accept-Charset, который 
по-умолчанию выдает Netscape Navigator 4.x - бредовый (для России во всяком 
случае) и не настраивается, а большинство остальных броузеров этот заголовок
вообще не выдают (исключение - lynx и хитро хаканые preferences.js для 
Netscape/X11).

Возможные варианты поведения сервера:

1) признать, что если приходит разумный Accept-Charset (т.е. запрос кодировки, 
известной серверу), то ТАКОЕ пожелание имеет НАИВЫСШИЙ приоритет. Как оно и 
должно быть по стандарту HTTP. В этом случае мы ОБЯЗАНЫ выдавать Vary:
  как по стандарту, так и по самой сути вещей (см выше примеры) даже если
этого заголовка нет в текущем запросе. Дело в том, что если в следующем запросе 
через тот же кэш такой заголовок таки появится, то кэш уже должен знать, что 
нужно обрабатывать варианты. Если Vary не будет в первом же ответе, то 
Accept-Charset во втором запросе будет проигнорирован кэшом и
  ответ (неправильный!) будет отдан из кэша.

  Поведение Russian Apache с настройками по-умолчанию соответствует стандарту,
  цитату мы тут уже мусолили.

 2) Можно считать, что клиентов с "правильным" Accept-Charset практически нет,
  а которые есть - сумеют выбрать нужную кодировку из менюшки "ваша кодировка".
  В этом случае мы выключаем обработку этого заголовка вышеописанной
директивой CharsetDisableAcceptCharset On и живем как люди - вариантность по 
этому параметру исчезает и мы честно не сообщаем о ней остальному миру
  (ее нет) - в ответах нету Vary: accept-charset.

В документации написано, но я на всякий случай повторю. Когда мы пишем
CharsetSelectionOrder aa bb cc
мы (сервер) на самом деле подразумеваем
CharsetSelectionOrder AcceptCharset aa bb cc
- это сделано из тех соображений, что способ описанный в стандарте - он
обязателен к выполнению, а остальное - Portnumber/Useragent - от лукавого.

 AT>> О. Скажите, откуда вы взяли заголовок Content-Charset - озолочу. А то я
 AT>> с вашей
 alr> Только бесплатно :) и только частично.
Все-таки я не понял.
Вы писали, что если в заголовке ответа будут заголовки
Vary:
Content-Charset:
Content-Language:

То MS IE 5.x такой ответ таки кэширует. Это так ?

А если Content-Charset убрать (он дублируется в Content-Type:), то тогда
кэширует ? Я не ради прикола спрашиваю - у меня нет MS IE 5 и попробовать
не могу, а качать эти мегабайты по 14400-16800 ради одного теста как-то тоже не 
хочется. А на работу я уже 3 недели не ходил, работаю дома :)

 alr> Первично (несколько лет назад) из
 alr> текстов поминавшейся уже альтернативной разработки.
Из какой такой альтернативной разработки ? HTTP-NG ? В настоящее время есть 
только один документ про HTTP/1.1 - RFC2068. Драфт устарел (expiration date 
прошла), а нового еще не вышло.
 alr> А потом видел на ряде немецких и тайваньский сайтов. Но этот всё было
 alr> достаточно давно и может так и не вошло в практику. Тогда извиняюсь за
 alr> отнятое время.
Если Content-Charset помогает MS IE5, то ее можно ввести в практику обратно.
Но должно быть какое-то б-м официально описаниее ее функциональности.

С уважением,Alex Tutubalin

p.s. Однако длинно получилось. Давайте как-то двигаться в этом обсуждении,
последние писем 10 мы говорим все об одном :)
--- GoldED 2.42.G1114+