Pull to refresh

Comments 25

В рамках симфони и 10 000 страниц стоит объединить это дело с кэшированием.
Строчек — не многим больше добавляется.
надо бы еще придумать, как прикрутить это к встроенному кешированию.
Вы не поверите. С отключенным кэшированием оно и работать не будет =)

Поэтому я и написал, что довольно странно рассматривать эти вещи отдельно.
имелось в виду, к кешированию блоков и страниц симфони.

И я про то.
Иначе откуда симфони возьмет последние время \ дату модификации блока )
Посмотрите в сторону Симфони 2.0. Знаю что там точно система кэширования выполняется перед инициализацией фреймворка, из-за чего прирост в производительности. Но по-моему там было что-то и с htaccess
2.0 это круто, но переводить несколько существующих, довольно сложных сайтов на настолько отличающийся фреймфорк, который к тому-же и довольно сырой, по меньшей мере рановато.
Полностью согласен. У самого было желание, но после ознакомления с сурсами и документацией оно само отпало :)
Часто меняющийся блок прогружать на страницу аяксом.

Это единственное решение, которое я придумал, чтобы и роботов не обманывать и блок не убирать.
Не знаю как другие, но робот Яндекса совершенно равнодушен к Last-Modified.
Плюс в другом, если уж задумались об этих заголовках — можно сразу прикрутить Expires для редко меняющихся или статических страниц. Тем самым снижаем нагрузку на сервер.
Вот он гад!!!

95.108.158.242 [27/Nov/2010:05:30:14 +0600] «GET /uploads/autos/table/d/d3/d3a5b548c24b210c97e0b2a6cb32cb9b.jpg HTTP/1.1» 304 0 "-" «Mozilla/5.0 (compatible; YandexImages/3.0; +http://yandex.com/bots)»

95.108.158.242 [27/Nov/2010:05:38:44 +0600] «GET /uploads/autos/table/0/09/0990b76daad021f3c454a1dad5743c4e.jpg HTTP/1.1» 304 0 "-" «Mozilla/5.0 (compatible; YandexImages/3.0; +http://yandex.com/bots)»
Как Вы наверное уже заметили, это робот YandexImages. Также поступает и YandexBlogs. Робот большого поиска тупо индексирует всё подряд.
Googlebot любит Last-Modified, но на ранжирование вся эта информация никак не влияет.
Разговор шел за скорость индексации, а не ранжирование.

Я питаю слабость к СЕОшникам, которые не умеют пользоваться поисковиками.

Я намекну.

www.google.com/search?q=%22htm+-+304%22+YandexBot
Тогда уж скорость не индексации, а кравлинга.

Тогда и это неизвестно. Ведь до проведения эксперимента не известно запрашивает робот страницы чаще, если получает 304 ответы.
Я вас уверяю — скорость кравлинга от этого никак не зависит. Инфа 100% :-)
Ведь Яндекс к ним равнодушен =)
т.е. он не посылает заголовок if-modified-since при повторном проходе?
Да даже если и посылает. Кравлинг далеко не самая долгая составляющая в процессе индексирования.
Очень интересная ситуация!

Из access.log
87.250.254.242 - - [30/Nov/2010:23:59:56 +0300] GET /slovo/poizi/671.htm HTTP/1.1 "200" 4240 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/ "-"

* This source code was highlighted with Source Code Highlighter.


Из моего кэтчера пауков:
Nov 30 23:59:56 symfony [err] [Yandex] Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) [If-Modified-Since: Tue, 23 Nov 2010 02:59:34 GMT][<хост>/slovo/poizi/671.htm]

* This source code was highlighted with Source Code Highlighter.


Код кэтчера такой:
$pattern = '/(google)|(yandex)|(scooter)|(stack)|(aport)|(lycos)|(fast)|(rambler)/msi';

    if(isset($_SERVER['HTTP_USER_AGENT']) && preg_match($pattern, $_SERVER['HTTP_USER_AGENT'], $out))
    {
      $bot = self::$se[strtolower($out[0])];
      $agent = $_SERVER['HTTP_USER_AGENT'];

      $message = '['.$bot.'] '.$agent.' [If-Modified-Since: '.(isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) ? $_SERVER['HTTP_IF_MODIFIED_SINCE'] : 'no').']['.$request->getUri().']';
      sfContext::getInstance()->getLogger()->err($message); 
    }


* This source code was highlighted with Source Code Highlighter.


Получается робот все спрашивает как надо!

If-Modified-Since запрашивается браузером по собственной инициативе или только в случае, если на свой первый запрос (когда страницы в его кэше ещё не было) он получил какие-то заголовки от сервера? Две ситуации интересует: сервер хочет чтобы его никогда спрашивали (даже если клиент умеет) и сервер хочет, чтобы его спрашивали всегда (если клиент умеет, конечно). По здравому размышлению браузер должен спрашивать, если Last-Modified был в ответе на первый вопрос, и не должен, если не было. А как в реальности? Да, и кажется, по стандарту браузер может спросить HEAD, а не GET запросом. Пользуются они этим.

P.S. Часто изменяющимся, но особо не значимым блоком можно, имхо, пренебречь при высоких нагрузках

Я с трудом представляю, что вам мешает проверить это.

HEAD от браузеров я не видел.

Как только проверите, узнаете, что еще есть Etag (привет nginx) и Cache-Control, а там и до чтения RFC не далеко.
Прежде всего интересует поведение «самого популярного браузера», запустить который на своей машине я по некоторым причинам не могу. Ну а после того, как ни один из проверенных мною браузеров корректно не обработал 301 и 302 коды возврата для POST запросов согласно RFC 2616 я предпочитаю уточнить у знающих людей насколько полно интересующие меня пункты реализованы.
Точно знаю что If-Modified-Since в FireFox 3.6 зависит от F5/Ctrl+F5.

Если открыть html страницу и нажать F5, запросы css/js файлов будут всегда (даже если время жизни кэша не истекло) делаться с If-Modified-Since (ответ сервера 304).
Ну и при нажатии Ctrl+F5 будут запросы без If-Modified-Since (ответ сервера 200).

Возможно есть ещё какие-то тонкости с BFCache и валидностью кэша (expires, etag).

Т.е. скорее всего ответ на ваш вопрос: да, браузер сам решает какие заголовки включить в запрос.
Про явное указание поддержки If-Modified-Since сервером кленту я ничего не знаю.

И ещё в обработке If-Modified-Since запросов есть ньюанс, некоторые версии IE отсылают заголовок в таком виде:
If-Modified-Since: Fri, 02 Nov 2007 09:50:36 GMT; length=13801
При ручном парсинге даты надо не забывать отбрасывать длину файла.

Как-то так :)
If-Modified-Since не будет взят из головы браузером и добавлен к запросу, если он не получал до этого дату последнего изменения документа.

В этом и был запрос.

Вы рассказываете об очевидной ситуации «пользователь заставил браузер забыть про имеющийся кэш».
Sign up to leave a comment.

Articles