|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 25 Mar 2002 18:59:05
To : Artem Chuprina
Subject : Re: кэши
--------------------------------------------------------------------------------
Artem Chuprina <ran@ice.ru> wrote:
> VM>>> А Last-Modified? Яндекс его требует и, надо думать, учитывает его
> VM>>> наличие, определяя релевантность. С другой стороны, MSIE ведет
> VM>>> себя несколько странно, если имеет только Last-Modified, а именно
> VM>>> - берет из кеша страницу, иной раз даже если она изменилась, а
> VM>>> чтобы обновить ее, приходится жать не просто "обновить", а Ctrl +
> VM>>> "обновить". Сие есть глюк, но надо с этим что-то делать. Hаверное,
> VM>>> будет правильно отдавать и Last-Modified и ETag, изменяющиеся в
> VM>>> зависимости от контента, а баннеры контентом не считать.
>
> AC>> Hу, в принципе, да. При условии, что ты умеешь посчитать ETag до того,
> AC>> как прикрутишь баннер. В принципе, насколько я понимаю, ETag-то как
> AC>> раз придуман для того, чтобы отличить изменение документа от изменения
> AC>> его представления типа перекодировки, если требуемое представление
> AC>> может произвести кэш. Правда, я не знаю кэшей, которые это адекватно
> AC>> умеют. Хотя вот oops, например, умеет перекодировать в кодировку,
> AC>> запрошенную клиентом, сам. Hо я не изучал, по каким правилам. Hо тут
> AC>> как раз ETag противоречит идее баннера, так что весь вопрос в том,
> AC>> хочешь ты его показать или наоборот.
>
> VM> Эксперимент показал, что наличие ETag (правда он показывался как "etag",
> VM> но вроде бы названия полей заголовков нечувствительны к регистру) проблему
> VM> с кешем не решает. Opera 6 ведет себя точно как MSIE. В то же время, в
> VM> отсутствие Last-Modified вещи начинают происходить как надо - при
> VM> изменении страницы сразу показывается новый вариант. Плюс в результате
> VM> прочтения соответствующей статьи стало ясно, что если отдаешь такие
> VM> заголовки, надо еще и обрабатывать запросы типа If-Modified-Since (кстати,
> VM> где можно поподробнее почитать об этом?) Черт, как все сложно :-)
>
> Суть проблемы, как я понимаю, в том, что браузер применяет некоторую эмпирику
> относительно Last-Modified - чем давнее modified, тем меньше вероятность, что
> изменился снова. Кэши тоже нередко такую эмпирику применяют. Если известно,
> когда он будет modified, то можно выдать Expires. Засада в том, что как
> правило, неизвестно. Hо при выдаче в пару к Last-Modified с небольшим временем
> вперед может дать хороший эффект. ETag же по сути применим только к
> HEAD-запросам, ибо если ты уже получаешь контент, то непонятно, зачем тебе
> ETag. С If-Modified-Since же все просто - если оно моложе, чем Last-Modified,
> выдаешь 304, кажется (Not Changed). Контент, соответственно, не выдаешь.
Я подозреваю, что на ETag современные броузеры просто кладут.
Единственное место, где я видел, что он используется - это If-Range.
Hо повторюсь - это лишь ощущения, тестов я пока не проводил.
--
Игорь Сысоев
http://sysoev.ru
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
