drupal и заголовки last-modified

Главные вкладки

Комментарии

Аватар пользователя ˛ ˛ 13 октября 2006 в 3:18

дык. прочел что сервер ни при чем, last-modified должен послать скрипт. Дрюпал видимо до этого не дорос. Или это впринципе нереально, либо неоптимально - посылать last-modified?

Аватар пользователя ˛ ˛ 13 октября 2006 в 23:00

прописать можно, но что известно про глюкалово с кэшем при отправлении last-modified?
Ведь почему-то же в стандартном дистрибутиве этого не сделали?

Аватар пользователя ˛ ˛ 28 октября 2006 в 23:08

2 kiev1

Quote:
это можно в хедерсах тему прописать - ничего сложного, last-modified извлекается из массива $node

Решил таки отправлять хиадер last-modified!
Т.к. слишком уж медленно дрюпал ползает на страницах, которые уже раньше были открыты.
Из $node мы извлечем дату, но это дата изменения узла?
а как насчет изменения блоков, статуса пользователя (вошел в систему/вышел из системы)?
kev1, что думаете по этому поводу?
Заранее благодарен

Аватар пользователя kiev1 kiev1 29 октября 2006 в 0:23

ничего не думаю - если страничка обновилась или блок странички - надо время изменения ставить или новое или если не важны блоки - то старое

Аватар пользователя rgb rgb 30 октября 2006 в 12:08

Гость wrote:
похоже это только для страниц из друпаловского стандартного кэша

Да вроде там пониже (под [b]if[/b]-ом) ещё [b]else[/b] есть - для остальных страниц. Там тоже прописывается Last-Modified (правда, настоящим моментом).

Или это я не в тему?

Аватар пользователя ˛ ˛ 30 октября 2006 в 17:54

Вы, уважаемый Rgb, всегда в тему, присаживайтесь к нашему столику Smile
А толку от last-modified настоящим моментом? Вот бы прошлым моментом его послать, но это столько всего... и изменения настроек блоков и изменения контента, выдаваемого блоками, изменение самих нод и т.д. То ли вместо друпала на php что-нибудь быстренько наляпать, то-ли смириться с друпалом Smile для разработчика друпал хорош, слов нет, а вот для конечного пользователя и для заказчика не всегда... особенно если нужен не портал а сайт-визитка и он не в состоянии осилить слов кэш и раскрутка Smile

Аватар пользователя rgb rgb 30 октября 2006 в 20:28

Рома wrote:
Вы, уважаемый Rgb, всегда в тему, присаживайтесь к нашему столику

За приглашение - спасибо Smile ..."уважаемый" - я прям сразу все свои годы и почувствовал на себе ;-))

Рома wrote:
А толку от last-modified настоящим моментом? Вот бы прошлым моментом его послать

Полагаю в этом случае логика разработчиков яснА: если страницы в кэше нет (второй if не сработал), то значит она только что сформировалась. Следовательно, надо и Last-Modified выставлять ей на сейчас. Соответственно, если б достали её (страницу) из кэша - это было бы признаком её более раннего существования. В этом случае Last-Modified выставляем по времени добавления этой страницы в кэш (т.е. "прошлым моментом").

Это всё для случая когда кэш в Дрюпале включен. Про вариант с выключенным пока не скажу ничего.

(Сорри, если объясняю и так понятные вещи...)

Рома wrote:
для разработчика друпал хорош, слов нет

Поверьте, и для разработчика сюрпризов хватает Smile

Рома wrote:
особенно если нужен не портал а сайт-визитка и он не в состоянии...

Думаю для сайта-визитки всё же лучше взять что-то "полегче" Дрюпала Smile

Аватар пользователя ˛ ˛ 31 октября 2006 в 4:49

rgb wrote:
логика разработчиков яснА:
Мне как-то в голову не приходило, т.к. кэш у меня всегда отключен Smile
Думаю, для случая, когда страничка не из кэша, можно поставить проверку, включен ли кэш, и если нет, то проверку вошел ли юзер, и если не вошел, то вставить проверку, которую делает кэш, решая кэшировать страницу или нет, и если страничка не изменилась, то брать из таблички no_cached_pages_last_modified дату ее последней модификации и отправлять в заголовке...

Аватар пользователя rgb rgb 31 октября 2006 в 9:45

Рома wrote:
Думаю, для случая, когда страничка не из кэша, можно поставить проверку, включен ли кэш,

Первый [b]if[/b] и проверяет - включён ли кэш, либо нет.

Рома wrote:
... и если не вошел, то вставить проверку, которую делает кэш, решая кэшировать страницу или нет

Это Вы про ту проверку, что заголовки HTTP-запроса проверяет?

Рома wrote:
и если страничка не изменилась, то брать из таблички no_cached_pages_last_modified дату ее последней модификации и отправлять в заголовке…

Ведение этой таблицы, как я понимаю, это забота пользователя (в том смысле, что её придётся добавлять ручками) или это уже в модуле каком-то реализовано?

И ещё вопрос: каковы причины отключения дрюпаловского кэша страниц?

Аватар пользователя ˛ ˛ 31 октября 2006 в 22:51

rgb wrote:
Первый if и проверяет - включён ли кэш, либо нет
Что-то я рассеяный стал...
rgb wrote:
Это Вы про ту проверку, что заголовки HTTP-запроса проверяет?
Честно говоря не знаю, что он проверяет (глянул page_set_cache() в common.inc, но там ничего особенного не проверяется, только ob_get_contents() - так и не понял, что это за функция )... а как он определяет кэшировать или нет? По идее должен был бы проверять дату изменения ноды и всех блоков... Или он тупо кэширует по истечении периода времени?
rgb wrote:
Ведение этой таблицы, как я понимаю, это забота пользователя (в том смысле, что её придётся добавлять ручками) или это уже в модуле каком-то реализовано?
думаю нигде не реализовано...для тестирования можно ручками...а в идеале не помешал бы модуль или исправления в стандартном дистрибутиве...
rgb wrote:
каковы причины отключения дрюпаловского кэша страниц?
слишком часто на него жалуются в форумах и при тестовом включении были глюки, да и посетителей не так много пока...

Аватар пользователя rgb rgb 1 ноября 2006 в 0:46

Рома wrote:
Честно говоря не знаю, что он проверяет (глянул page_set_cache() в common.inc, но там ничего особенного не проверяется, только ob_get_contents() - так и не понял, что это за функция )…

ob_get_contents просто возвращает контет буфера вывода. Ключевые слова: "output buffering", ob_start/ob_get_contents/ob_XXXXX....

Рома wrote:
а как он определяет кэшировать или нет? По идее должен был бы проверять дату изменения ноды и всех блоков… Или он тупо кэширует по истечении периода времени?

Угу - всё проще гораздо. В page_set_cache() проверяется:

  • что текущий пользователь - аноним
  • что метод запроса - GET

И только в этом случае страница сохраняется в кэше (разумеется, если он включен).

Т.е. кэшируются только обычные страницы (не POST-запросы) для анонимов и всё Smile А по истечении какого-то периода (см. в настройках) или при возникновении какого-то события (типа добавления нового нода) происходит сброс этого кэша страниц и при следующем запросе страничка строится заново и кэшируется.

Это примерная схема работы кэша.

Рома wrote:
думаю нигде не реализовано…для тестирования можно ручками…а в идеале не помешал бы модуль или исправления в стандартном дистрибутиве…

Ну хорошо, реализуем мы эту штуку. Вопрос - зачем? Что б при отключенном кэше выдавать иногда 304-й код? Боюсь, что для определения того факта, что страница не изменилась придётся как минимум сгенерить её (страницу) и опять где-то хранить признак, по которому можно определить, что она изменилась (или нет)... Короче - аналог уже реализованного кэша получается Wink

Или я не понял идею?

rgb wrote:
каковы причины отключения дрюпаловского кэша страниц?

Рома wrote:
слишком часто на него жалуются в форумах и при тестовом включении были глюки, да и посетителей не так много пока…

Во-во... народ часто жалуется, а я чего-то понять не могу с чего жалуется. Вот и выспрашиваю Smile

Из того, что я понял: народ отключает кэш, т.к. при его использовании Дрюпал начинает выставлять заголовки, типа Last-Modified и Cache-Control. А не все браузеры одинаково к ним (к заголовкам) относятся и поэтому кое-где (в основном на IE) случаются глюки (например, не обновляется страница).

[b]2Народ[/b]: Может кто разбирался в этом вопросе? Подтвердите/опровергните, плиз!

Аватар пользователя emzi emzi 1 ноября 2006 в 11:23

начинал глючить вывод, если заходить попеременно ie и firefox'ом. вроде бы связано с выводом в сжатом/несжатом виде

Аватар пользователя rgb rgb 1 ноября 2006 в 11:29

emzi wrote:
начинал глючить вывод, если заходить попеременно ie и firefox’ом.

Имеется ввиду ситуация, когда на сайте несколько посетителей и у некоторых - FF, а у других IE. И они все - анонимы. Когда начинают гулять по сайту, у них с отображением глюки начинаются. Я правильно понял?

Аватар пользователя ˛ ˛ 3 ноября 2006 в 23:16

rgb wrote:
[url=http://www.php.net/manual/en/function.ob-get-contents.php]ob_get_content... просто возвращает контет буфера вывода. Ключевые слова: "output buffering", ob_start/ob_get_contents/ob_XXXXX....
Благодарю за разъяснения.
rgb wrote:
Ну хорошо, реализуем мы эту штуку. Вопрос - зачем? Что б при отключенном кэше выдавать иногда 304-й код? Боюсь, что для определения того факта, что страница не изменилась придётся как минимум сгенерить её (страницу) и опять где-то хранить признак, по которому можно определить, что она изменилась (или нет)… Короче - аналог уже реализованного кэша получается

Или я не понял идею?
Идея такая: у каждого модуля/блока (и любого объекта) свой кэш. Если объект состоит из нескольких объектов, у каждого из которых есть кэш, то для родительского объекта тоже генерируется кэш. Таким образом реализуется многоуровневое кэширование, на вершине которого стоит кэш страницы.
При перегенерации любого объекта для него сохраняется дата перегенерации.
Решение о перегенерации объекта принимается на основе событий.
Когда броузер запрашивает страницу, тогда либо инициируется событие (события), которое инициирует перегенерацию отдельных объектов и изменение в базе даты перегенерации, либо, если перегенерация объектов, которые влияют на отображение страницы, не производилась, то берется дата последней перегенерации и отправляется броузеру как last-modified. Если в кэше браузера есть страница с таким last-modified, то он молниеносно загружает ее из кэша, а если нет, то запрашивает ее у друпала, который выдает страницу из своего кэша...

но это видимо должно быть реализовано в каждом модуле/блоке...
мечтать, как говорится, не вредно Smile

Аватар пользователя ˛ ˛ 3 ноября 2006 в 23:36

Идеальный вариант:
Измененный контент подгружается в скрытый iframe и вставляется в innerHTML целевых div'ов. Поисковикам, в силу их технической консервативности/отсталости, выдается страница целиком.

Или, например, как реализована [url=http://www.rsdn.ru/]rsdn.ru[/url]:
Панели сайта являются фреймами, а ноды грузятся в отдельный фрейм.
Панели перезагружаются только по необходимости. Подгрузка элементов меню происходит через AJAX. Сайт сделан на ASP.Net.

Простите меня за мечты Smile

Аватар пользователя rgb rgb 3 ноября 2006 в 23:59

Рома wrote:
Идея такая: у каждого модуля/блока...

Если у Вас есть желание развить и обсудить эту тему, я приму в этом участие. В частности, остаются не ясными хотя бы такой момент: как во время запроса определить все составляющие страницы (блоки, ноды...), не генирируя её (страницу) полностью? Ведь без этого, мы не получим "время последней модификации" данной страницы.

Только предлагаю завести для этого отдельный топик.

Рома wrote:
Или, например, как реализована rsdn.ru:
Панели сайта являются фреймами, а ноды грузятся в отдельный фрейм.
Панели перезагружаются только по необходимости. Подгрузка элементов меню происходит через AJAX. Сайт сделан на ASP.Net.

Вы предлагаете Дрюпал на ASP.NET переписать!? Wink

Ну а если серьёзно: можно и так сделать, и через "скрытый iframe"...

И я думаю, даже на существующей базе это реализовать можно: PHPTemplate (да и сам Drupal) - весьма гибкая штука.

Только (IMHO) это вызовет другие проблемы, чем те, которые мы решаем сейчас, а задачу свою (донесение пользователю информации) сайт так и будет решать. Так стоит ли менять шило на мыло?

...тем более, что Дрюпалом рулим не мы Wink

Рома wrote:
Простите меня за мечты

Прощаем... Smile
Собственно, чего извиняться? Мечты (как и лень!) - это ж двгатель прогресса Smile