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

["Eugene B. Byrganov" <E.B.Byrganov@inp.nsk.su>]

Hi!

> Давайте рассмотрим сначала пример с Accept-Language и включенным MultiViews.
> Принципиально он ничем не отличается от Accept-Charset, разница лишь в том, что 
> большинство броузеров ставят хоть какой-то Accept-Language и пример будет
> более ярким.
> 
> Пусть все ходят через прокси-кэш по протоколу HTTP/1.1, а сервер знает все
> языки.
Здесь собака и зарыта, где есть прокси с HTTP/1.1????????
А squid-у 2.x точно не нужно выдавать Vary!!! (Expire кстати выдается
только по слабым признакам!!!

> Если не выдавать Vary, то первый клиент (скажем, с Accept-Language: zh)
> вытянет через прокси какой-то документ (в китайском варианте), который залипнет 
> в кэше. После чего второй клиент (Accept-Language: cz) сможет получить чешский 
> вариант только нажав Shift-Reload в своем броузере (если он это умеет делать, 
> обычные пользователи об этой фиче не знают). Без этого он будет получать
> (из кэша) китайский вариант.
> 
> Предположим, первым клиентом была какая-нибудь Altavista или CoolSearch,
> который не поставил Accept-Language, но пришел через тот же кэш. Сервер выдаст 
> ему документ в соответствии с DefaultLanguage (например, cr), который залипнет 
> в том же кэше. После чего все клиенты кэша начнут получать корейский вариант.
Так как реального прокси с HTTP/1.1 нет, то можно предположить что
кэш будет расматривать отсутствие Accept-Language будет раматривать как
еще один Accept-Language (например с '*' - это кстати соответствует RFC)
или же может быть настроен на определенный язык, и сам его
будет подставлять, как он уже делает с Host:
И еще, возможно он будет учитывать Content-Language и charset в Content-Type,
и если пришел Accept-Language: ru, a в кеше Content-Language: cr. то
сам без Vary полезит на сервер!!!! 
Вообшем предположении можно строить разные пока он не появиться.

> 
> 
> Теперь вернемся к ситуации с Accept-Charset. Она ничем не отличается от 
> Accept-Language, за тем исключением, что тот Accept-Charset, который 
> по-умолчанию выдает Netscape Navigator 4.x - бредовый (для России во всяком 
> случае) и не настраивается, а большинство остальных броузеров этот заголовок
> вообще не выдают (исключение - lynx и хитро хаканые preferences.js для 
> Netscape/X11).
> 
> Возможные варианты поведения сервера:
> 
> 1) признать, что если приходит разумный Accept-Charset (т.е. запрос кодировки, 
> известной серверу), то ТАКОЕ пожелание имеет НАИВЫСШИЙ приоритет. Как оно и 
> должно быть по стандарту HTTP. В этом случае мы ОБЯЗАНЫ выдавать Vary:
Если HTTP/1.1 !!!!!
>   как по стандарту, так и по самой сути вещей (см выше примеры) даже если
> этого заголовка нет в текущем запросе. Дело в том, что если в следующем запросе 
> через тот же кэш такой заголовок таки появится, то кэш уже должен знать, что 
> нужно обрабатывать варианты. Если Vary не будет в первом же ответе, то 
> Accept-Charset во втором запросе будет проигнорирован кэшом и
>   ответ (неправильный!) будет отдан из кэша.
> 
>   Поведение Russian Apache с настройками по-умолчанию соответствует стандарту,
>   цитату мы тут уже мусолили.
> 
>  2) Можно считать, что клиентов с "правильным" Accept-Charset практически нет,
>   а которые есть - сумеют выбрать нужную кодировку из менюшки "ваша кодировка".
>   В этом случае мы выключаем обработку этого заголовка вышеописанной
> директивой CharsetDisableAcceptCharset On и живем как люди - вариантность по 
> этому параметру исчезает и мы честно не сообщаем о ней остальному миру
>   (ее нет) - в ответах нету Vary: accept-charset.
> 
> В документации написано, но я на всякий случай повторю. Когда мы пишем
> CharsetSelectionOrder aa bb cc
> мы (сервер) на самом деле подразумеваем
> CharsetSelectionOrder AcceptCharset aa bb cc
> - это сделано из тех соображений, что способ описанный в стандарте - он
> обязателен к выполнению, а остальное - Portnumber/Useragent - от лукавого.
Я сам думал об необходимости AcceptCharset в CharsetSelectionOrder в
явном виде, но как реальный пользователь Accept-Charset пришел к выводу об
его вредности - так что я против, а свой вариант я написал в другом 
письме.



Мое общее резюме такое: пока нет не одного нормального клиента и кеша
с HTTP/1.1 - то вопрос об Vary можно отложить, а для HTTP/1.0 не ставить 
вообще.

-- 

                      С наилучшими пожеланиями, Евгений Бырганов.
                      Best regards, Eugene Byrganov.

  mailto:E.B.Byrganov@inp.nsk.su
  work - http://www.inp.nsk.su/