Название: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 22 февраля 2007, 08:44:59 Сейчас НС не может использовать заложенный в HTTP механизм времени устаревания (expiration). Сервер часто посылает в ответе в поле "Expires:" или "Cache-Control: max-age=" дату/время, до истечения которой файл точно изменяться не будет. До этого времени мы смело можем не обращаться к серверу невзирая на содержание списков "Только из кэша" и "Не обновлять", не проверять If-Modified-Since, а смело выдавать файл из кэша. Для этого нам надо сохранять указанное поле (max-age, а при его отсутствии Expires) в индексе. А, собственно, зачем нам ждать появление индексов, которые неизвестно когда/если будут?! ;) Предлагаю вариант реализации данной возможности без использования индексов! Можно писать дату устаревания прямо в дату модификации сохраняемого в кэш файла! Например, когда в заголовках ответа сервера есть информации об устаревании контента (Cache-Control: s-maxage=... , Cache-Control: max-age=... , Expires:... и т.п.), то мы меняем дату модификации файла на (system_time + s-maxage) или на (system_time + max-age) или на Expires... С целью уменьшения нагрузки на файловую систему не изменять в кэше дату модификации файла (оставлять дату, присвоенную файловой системой): 1. Если в заголовках нет данных о времени устаревания контента или сервер не разрешает нам его кэшировать (max-age=0, no-cache и т.п.). 2. Если значение заголовка Expires < текущей системной даты. 3. Если (Expires - system_time), s-maxage или max-age не попадают в настраиваемый интервал. По умолчанию: min=10 минут, max=1 год. Выгода: В следующий раз, когда нам понадобится файл, HC как и сейчас проверит его дату в кэше, и если она окажется больше системной даты, то вместо проверки списка "Не обновлять", формирования заголовка "If-Modified-Since" и отправки запроса на сервер HC сразу отдаст файл из кэша "200 From cache (HC)" либо просто ответит браузеру "304 Not Modified (HC)"! Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 22 февраля 2007, 12:24:33 DenZzz
А как отнесутся система/стороннее ПО к дате изменения, превышающей текущую и/или дату последнего доступа? Думаю, не очень хорошо. Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 22 февраля 2007, 12:42:57 DenZzz А как отнесутся система/стороннее ПО к дате изменения, превышающей текущую? Системе абсолютно все равно! Можно менять дату файлов хоть на год вперед, хоть на 2 - проглотит без вопросов! А как поведет себя стороннее ПО, зависит от степени его "кривизны"! ;) Во-первых, какое этому стороннему софту дело до дат в кэше HC ? Во-вторых, если не все равно, то это же должно где-то у них отключаться/настраиваться! Помню, что древние Нортоновские утилиты ругались на "будущую" дату, но это легко отключалось... Мой антивирус вообще равнодушен к датам файлов... Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 22 февраля 2007, 14:57:29 DenZzz
Цитировать А как поведет себя стороннее ПО, зависит от степени его "кривизны"! Остается осадок, что "кривизну"-то вносим как раз мы. :)Сделать так в принципе можно, согласен. Для начала хотя бы опционально, чтоб потестировать можно было да и отказаться при возникновении проблем. Только как в этом случае (при проблеме) даты взад исправить? Ведь программы бета-тестирования не существует... А можно и потерпеть до индексов или чего там еще ;) Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 22 февраля 2007, 15:37:51 Остается осадок, что "кривизну"-то вносим как раз мы. :) Сделать так в принципе можно, согласен. Для начала хотя бы опционально, чтоб потестировать можно было да и отказаться при возникновении проблем. Можешь назвать софт, который будет работать с кэшем HC и не приемлет "будущие" даты? Кроме старых Нортоновских утилит, которые так и норовят эти даты сделать текущими, я больше не встречал! Цитировать Только как в этом случае (при проблеме) даты взад исправить? Легко! Тем же Total Commander-ом или FAR-ом! Но думаю, это не пригодится... Цитировать Ведь программы бета-тестирования не существует... Собственно, сейчас все версии HC c буковкой "b", т.е. беты, а все пользователи - "бета-тестеры"! :) Вот выйдет версия 1.0 - назовем ее "релизом"! Цитировать А можно и потерпеть до индексов или чего там еще ;) Боюсь, терпеть придется долго... ;) То, что я предлагаю, сделать проще, т.к. все для этого у HC уже есть! А когда будет готов основной алгоритм обработки даты устаревания, изменить место ее хранения в случае необходимости - проще простого! Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 22 февраля 2007, 17:31:39 DenZzz
Цитировать Можешь назвать софт, который будет работать с кэшем HC и не приемлет "будущие" даты? Нет. Но остаются опасения, что это не гарантирует действительное отсутствие такого софта. А историк туда часом не лезет?Цитировать мы меняем дату модификации файла на (system_time + s-maxage) или на (system_time + max-age) или на Expires... Вместо system_time предлагаю брать содержимое поля Date: заголовка ответа.Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 23 февраля 2007, 01:50:40 DenZzz
Цитировать 3. Если (Expires - system_time), s-maxage или max-age не попадают в настраиваемый интервал. По умолчанию: min=10 минут, max=1 год. Не вижу смысла в параметре "max". Что он дает?Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 23 февраля 2007, 12:20:12 А историк туда часом не лезет? Во время текущей работы - нет. Он берет даты из файлов очереди последних посещённых ссылок, формируемой HC. А вот при первом наполнении истории по файлам кэша - я не в курсе, какую дату он использует. Но думаю, если он смотрит дату модификации и она оказалась больше системной, то он может брать дату создания или дату доступа. Цитировать Вместо system_time предлагаю брать содержимое поля Date: заголовка ответа. Считаю, что время прохождения запроса от его отправки до приема составляет максимум несколько секунд, поэтому им можно принебречь! Мы уже обсуждали это в теме: "Сохранять или нет даты, переданные с сервера? (http://handycache.ru/component/option,com_smf/Itemid,10/topic,206.0/)" Цитировать Не вижу смысла в параметре "max". Что он дает? Мне попадались на глаза сервера, где был 2030 год в Expires! Думаю, хранить такие даты бессмысленно - вряд ли файл долежит в кэше до 2030 года... Поэтому предлагаю параметр max обрабатывать так: если (Expires - system_time), s-maxage или max-age > max , то в кэш пишем дату (system_time + max) . Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 23 февраля 2007, 13:50:51 DenZzz
Цитировать Считаю, что время прохождения запроса от его отправки до приема составляет максимум несколько секунд, поэтому им можно принебречь! Мы уже обсуждали это в теме: "Сохранять или нет даты, переданные с сервера?" Там предложение пренебречь еще как-то можно было понять, т.к. Date: хранить негде было. Зачем пренебрегать теперь, если можно и правильно этого не делать? Date: у нас есть, max-age и s-maxage указываются относительно него. Какие проблемы?Цитировать Мне попадались на глаза сервера, где был 2030 год в Expires! Думаю, хранить такие даты бессмысленно - вряд ли файл долежит в кэше до 2030 года... Мне тоже попадались такие. Ничем не хуже, чем "не обновлять никогда". Однако ж последнее мы с легкостью допускаем в списке "Н". Пусть остается 2030 г. Есть у пользователя сомнения - отключит "чтение из кэша", и URL проверится на обновление.Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 23 февраля 2007, 19:22:31 Date: у нас есть, max-age и s-maxage указываются относительно него. Какие проблемы? Если бы время на сервере и клиенте было строго синхронизировано с GMT, то и в этом случае разница в несколько секунд никому не важна - только лишние траты ресурсов на анализ заголовка Date! А когда время рассинхронизировано, то (system_time + max-age) будет даже точнее! Цитировать Мне тоже попадались такие. Ничем не хуже, чем "не обновлять никогда". Однако ж последнее мы с легкостью допускаем в списке "Н". Пусть остается 2030 г. Если бы была хоть малейшая уверенность, что файл действительно пролежит в кэше или на сервере до указанного времени и понадобится вновь в 2030 году, то был бы смысл сохранять такую большую дату... Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 23 февраля 2007, 21:58:18 DenZzz
Цитировать разница в несколько секунд никому не важна "Несколько секунд" бывает не всегда. Возьми, например, http://www.nnm.ru/favicon.ico. Там набегает 11 часов.Цитировать Если бы была хоть малейшая уверенность, что файл действительно пролежит в кэше или на сервере до указанного времени и понадобится вновь в 2030 году, то был бы смысл сохранять такую большую дату... Непонятно, чем эта уверенность, исходящая от автора сайта, хуже нашей уверенности в том, что URL никогда (хоть до 3000 г.) не обновится?Цитировать А вот при первом наполнении истории по файлам кэша - я не в курсе, какую дату он использует. Но думаю, если он смотрит дату модификации и она оказалась больше системной, то он может брать дату создания или дату доступа. Можешь спросить у автора?Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 23 февраля 2007, 22:43:10 "Несколько секунд" бывает не всегда. Возьми, например, http://www.nnm.ru/favicon.ico. Там набегает 11 часов. У меня на GPRS выходит максимум 10 секунд и это с учетом запроса на DNS-сервер: Цитировать 23.02.2007 23:10:25 # 877: DNS resolve www.nnm.ru --> 89.111.180.41 23.02.2007 23:10:32 # 877 >>> URL: http://www.nnm.ru/favicon.ico Connected to host: 89.111.180.41, port: 80 23.02.2007 23:10:32 # 877 >>> URL: http://www.nnm.ru/favicon.ico GET /favicon.ico HTTP/1.1 ... 23.02.2007 23:10:35 # 877 <<< URL: http://www.nnm.ru/favicon.ico HTTP/1.1 200 OK Цитировать Непонятно, чем эта уверенность, исходящая от автора сайта, хуже нашей уверенности в том, что URL никогда (хоть до 3000 г.) не обновится? Сомневаюсь, что эта уверенность у него есть! Думаю, он просто шутит... Цитировать Можешь спросить у автора? rs в последнее время редко бывает на форуме. Может, кто из пользователей Историка подскажет... Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 23 февраля 2007, 22:54:59 DenZzz
Цитировать У меня на GPRS выходит максимум 10 секунд и это с учетом запроса на DNS-сервер Не, я не про это.Запрос: (послан сегодня в 18.10 GMT, т.е. это system_time): GET /favicon.ico HTTP/1.0 User-Agent: Opera/9.20 (Windows NT 5.1; U; ru) Host: www.nnm.ru Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: ru,ru-RU;q=0.9,en;q=0.8 Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 Accept-Encoding: gzip, deflate Referer: http://www.nnm.ru/ Proxy-Connection: close Ответ: HTTP/1.1 200 OK Server: nginx/0.3.33 Date: Fri, 23 Feb 2007 07:23:55 GMT Content-Type: image/x-icon Content-Length: 197 Last-Modified: Sun, 10 Dec 2006 14:06:15 GMT Expires: Fri, 02 Mar 2007 07:23:55 GMT Cache-Control: max-age=604800 Accept-Ranges: bytes Proxy-Connection: Close Т.о., Date: < system_time ~ на 11 часов. Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Сергей от 23 февраля 2007, 23:32:09 Т.о., Date: < system_time ~ на 11 часов. У меня время совпадает. Как ты этого добился? Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 23 февраля 2007, 23:33:57 Михаил
Цитировать Запрос: (послан сегодня в 18.10 GMT, т.е. это system_time) Ты где живешь? На Гринвиче? ;) У меня местное время = system_time = GMT+4 = MSK+1 Цитировать Т.о., Date: < system_time ~ на 11 часов. Не, у меня время в Date было правильное! Гораздо больше распространен вариант - когда на сервере время правильное, а у пользователя сбито! Тогда логичнее считать время устаревания, как (system_time + max-age). Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 24 февраля 2007, 00:08:07 Сергей,
DenZzz Только что послал опять - опять то же самое. Давайте разберемся, тем более что это далеко не единичный, а частый расклад. Как ответил сервер у вас при запросе этого URL (http://www.nnm.ru/favicon.ico)? Цитировать Ты где живешь? На Гринвиче? Специально привел свой system_time в GMT, чтоб показать разницу с Date:.У меня местное время = system_time = GMT+4 = MSK+1 Цитировать Не, у меня время в Date было правильное! Оно и так, и так может быть правильное. Как мне помнится, Date - это не текущее время сервера или вышестоящего прокси в момент начала коннекта с нами, а время, когда он сформировал тот ответ, который направляет нам. Сформировать его он мог гораздо раньше (в данном случае на 11 часов) в ответ на запросы других пользователей. И не менять его, зная, что ни одно поле пока не подлежит изменению.Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 24 февраля 2007, 10:56:04 Давайте разберемся, тем более что это далеко не единичный, а частый расклад. Как ответил сервер у вас при запросе этого URL (http://www.nnm.ru/favicon.ico)? Так же, как и вчера, у меня время в Date правильное: Цитировать 24.02.2007 11:35:22 # 106 <<< URL: http://www.nnm.ru/favicon.ico HTTP/1.1 200 OK Server: nginx/0.3.33 Date: Sat, 24 Feb 2007 07:35:19 GMT Content-Type: image/x-icon Content-Length: 197 Last-Modified: Sun, 10 Dec 2006 14:06:15 GMT Connection: close Expires: Sat, 03 Mar 2007 07:35:19 GMT Cache-Control: max-age=604800 Accept-Ranges: bytes Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 24 февраля 2007, 17:10:03 DenZzz
Посмотри: http://www.nnm.ru/img/default/bg/winter/7.jpg http://www.nnm.ru/img/default/logo/winter/7.gif http://www.nnm.ru/img/default/razdel/topmenu/newz.gif И еще много с этого сайта. http://www.gks.ru/wps/menu/menu_service.js и куча URL с этого сайта. http://www.allbest.ru/i/gray.gif http://www.allbest.ru/i/corner.jpg И куча URL с этого сайта. Я взял 4 произвольных сайта методом тыка. И из них в 3 - такое есть. Да далеко и ходить не нужно: взял http://handycache.ru/forum/Themes/SlickPro_Graphite/images/staradmin.gif - там и еще в куче фалов каталога .../images/ тоже Date из далекого прошлого указывается. Частое несоответствие значения поля Date текущему времени - это факт. Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: DenZzz от 24 февраля 2007, 20:44:12 Михаил
Пробежался почти по всем твоим ссылками - везде время в Date правильное! Разница с моим системным всего несколько секунд! Только на http://www.gks.ru/ их Date спешит yна 5 минут... Ни о каких больших разницах речи нет! Проблема где-то на твоей стороне! Либо твой провайдер слишком агрессивно кэширует, либо какой твой софт портит тебе заголовки, либо ты что-то путаешь... ;) Название: Re: Использование времени устаревания (expiration mechanism) Отправлено: Михаил от 24 февраля 2007, 21:20:36 DenZzz
Реально - это провайдер. Присмотрелся - такое происходит со всеми рисунками и явой. За свой софт "зуб даю" ;) - не делает такого. Но как бы то ни было, мне придется отталкиваться от поля Date, иначе max-age будет работать неправильно.
Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com |