Re: [apache-rus] Vary и так далее

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

Hi,

> резюмирую появившеся рациональное зерно:
> Вариант 1:
> 1) если ответ выдается в HTTP/1.0, то Vary не выдавать
Это само по себе не бывает, значит для всех нужно ставить force-response-1.0!!!
чтобы squid версии 2.x мог кешировать. И кто знает, какие грабли из этого 
вылезут: у кого-нибудь не заработает модуль и т.д.

> 2) для MS IE 4/5 сделать force-response-1.0 в кодировке по-умолчанию
> 
> Вариант 2:
> (imho, противоречащий RFC)
> Если запрос был HTTP/1.0, то Vary не выдавать
А по моему не очень (противоречит), это показатель его понятливости.
Я как раз тут делаю upgrade для сервера, и заодно по разбирался со squid-ом.
Во первых, он (squid) все равно возвращает клиенту HTTP/1.0 и Vary там
могут не присутствовать. Во вторых, сами Vary нужны кешу (на кой они нужны 
клиенту?), так что клиент может обойтись и без них, естественно речь
идет об Accept-Charset и User-Agent - какие у него есть, такие и есть.
Если же появится кеш полностью разбирающейся с Vary, то не грех
сообщить об этом в виде HTTP/1.1. Желательно, конечно, списаться
с авторами squid, что бы согласовать поведение, но нужен хороший 
английский -((((.

А для MSIE 4/5 все же лучше проверять force-no-vary, зачем ждать
"общепринятой практикой" - общая задача поставлена и каждый модуль сам 
проверяет force-no-vary, что не исключает впрочем проверку 
на force-response-1.0.  Хотя у меня есть большое подозрение, что плохое
поведение его связано с ответом squid-а: HTTP/1.0 .


P.S. Во общем, следовать RFC раньше времени опасно, что придумают
другие всегда загадка, и не очевидно что так как мы думаем.
На очереди ETag: - для чего он нужен, один бог знает.


-- 

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

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