Re: [apache-rus] Vary

[Iouri Kharon <bc-info@styx.cabel.net>]

   Hi Alex!

Tuesday, May 11, 1999, you wrote:



AT>  AT>> то мы получим документ в ibm866 вне зависимости от установок приоритета
AT>  AT>> выбора. Обратите внимание, Vary: user-agent оно не ставит.
AT>  olr> Да но мы же не говорили Accept-charset? Более того, я вообще не видел
AT>  olr> таких запросов от msie. Только language :(
AT> А при чем тут MS IE ? Вся эта некэшируемость сделана для того, чтобы документ
AT> не залипал в транзитных proxy caches. Потому как пользователю всегда нужно
AT> кэшировать, а документ не в той кодировке в proxy реально мешает.
Что, proxy-server запросы посылает? :) Я говорил о том, что msie не посылает
поля accept-charset в запросе. Для чего сделана некэшируемость очевидно, но,
к сожалению, возможности сказать не кэшировать _только_ прокси-серверам
нету. И ровно так же это воспринимают и клиентские браузеры.

AT> Честно скажу, я не знаю HTTP/1.1-совместимых proxy, но это еще не повод
AT> нарушать стандарты. А стандарт в данном случае гласит - если есть "измерение"
AT> в котором мы можем что-то менять, то об этом нужно сказать клиенту.
Согласен. Но _только_ если менять можем. Ещё раз повторюсь - клиент
прислал accept-charset? Вот для него и ставим Vary. Клиент определился
"неоднозначно" (т.е. по браузеру или другим "слабым" признакам) - тоже
ставим. А для ситуации когда признак "сильный" (например порт), а клиент ни о
каких accept-cahrset не спрашивал, оно мешает. Ибо для таких клиентов (msie
это один из них) служит признаком того что документ "требует переговоров" с
сервером и не может кэшироваться.

AT>  olr> "компьютерном") смысле, т.е.  - этот документ есть предмет для
AT>  olr> "переговоров" с сервером. Вот потому-то я с мс и согласен,- если по
AT>  olr> поводу документа надо связываться с сервером, то как можно его
AT>  olr> кэшировать?
AT> В каком смысле "как" ? Заголовок vary указывает что именно должно поменяться,
AT> чтобы изменился content. Т.к. эти заголовки не меняются, то и content должен
AT> остаться прежним.
Почти. Это утверждение справедливо (наверное) для ситуации когда заголовок
клиентской посылки содержал content-charset. А я говорю о ситуации когда
клиент ничего подобного не посылал.

AT>  olr> бы агент понимающий отличия в charset _не_ кэшировал документ.
AT> Nope. Если агент выдает два запроса с разными accept-charset, то он получит два
AT> разных документа. Если с одинаковыми - два одинаковых.
Замечательно. А если он выдаёт запрос _без_ этого поля?

AT>  AT>> Vary: accept-charset ставится всегда, когда обработка Accept-Charset
AT>  AT>> не выключена. Я уже раз 5 это пишу :).
AT>  olr> А я тот же раз пишу, что её надо здесь давить :)
AT> А почему ?
AT> Вот пришел через прокси хаканый нетскейп, который выдает Accept-Charset.
AT> Если мы что-то давим, то документ зависнет в кэше и следующий клиент огребет
AT> этот документ в старой кодировке. Что же в этом хорошего ?
Логично. Но я же и предлагаю - _если_ клиент задал нам accept-charset или
признаки слабые - ставим. Если оба условия не выполнены - нет. Тогда
сработает нормально и в вышеописанной ситуации, и в той о которой говорил я.

AT>  olr> Кстати о CharsetAutoredirect - а нельзя добавить
AT>  olr> CharsetAutoRedirectDefault? В том смысле, что если все остальные не
AT>  olr> сработали перекидывать сюда. Это позволит делать автомат для "нерусских"
AT>  olr> агентов при заходе на рускоязычные страницы
AT> А как вы отличите русский агент от нерусского ? Вот у меня, скажем,
AT> Netscape/X11. Как узнать - есть у меня русские шрифты или нет ?
Ну, например, так. Если в accept-language присутствует ru, значит хоть какие-то но
есть (тем более, если есть accept-charset). А если отсутствует... Это, конечно,
может и ничего не значить, но ведь администратора никто не заставляет пользоваться
этим - это же _возможность_. Зато, если она будет, можно для таких клиентов
поставить автоматический редирект на английские тексты. Да, некоторое число наших
соотечественников, могут на это нарваться, зато существенно большая часть
зарубежных перестанет недоумённо смотреть на "кракозябры" :). Я, правда,
исхожу из того, что большинство пользователей работает в хоть как-то
настроенных браузерах. В конце-концов форточки сами определяются, а lynx
используют люди имеющие, как правило, хоть отдалённое представление о том
как с ним работать :)


С уважением,
 Ю. Харон                            mailto:bc-info@styx.cabel.net