|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Artem Chuprina 2:5020/400 25 Mar 2002 13:51:35
To : Victor Mironov
Subject : Re: Re^2: Re^2: Re^2: Re^2: кэши
--------------------------------------------------------------------------------
Здравствуй, Victor Mironov.
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). Контент, соответственно, не выдаешь.
--
Artem Chuprina
Communiware.net
RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/358.49, ICQ: 13038757
--- ifmail v.2.15dev5
* Origin: Leninsky 45 home network (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
