3. Баг кэширования несуществующих страниц

При стандартном кешировании Друпал сохраняет в кеш несуществующие страницы. Например, у нас есть сайт example.com, на котором имеются следующие страницы:

example.com/catalog
example.com/catalog?page=1
example.com/catalog?page=2
...
example.com/catalog?page=1000

Т.е. Друпал кеширует эти страницы через cache_set($base_root . request_uri(), $data, 'cache_page', CACHE_TEMPORARY, drupal_get_headers());. Но проверку на существование страницы request_uri() не делает... И если мы будем запрашивать несуществующие страницы, например:

example.com/catalog?page=1001
example.com/catalog?page=1002
...

и так до бесконечности, то Друпал будет сохранять в таблицу cache_page весь этот хлам. В качестве сохраняемых данных будет браться запись из последней существующей страницы (example.com/catalog?page=1000).

В итоге, если запустить на такой сайт бота, который будет делать подобные запросы, таблица cache_page очень быстро разрастется до огромных разделов.


Баг заметил sinkora

Комментарии

В итоге, если запустить на такой сайт бота

>>таблица cache_page очень быстро разрастется до огромных разделов"

и что делать?
Не запускать кеширование? Или я невнимательно читал и пропустил способ борьбы с этим багом?

А здесь не предлагается

А здесь не предлагается способов борьбы, здесь констатируется, что таковой баг имеет место быть.
Бороться можно по-разному. Можно кэш чистить своевременно, можно какие-либо правила для mod_rewrite придумать, чтобы отсекать лишние страницы. Понятно, что всё это костыли - а что делать?

Надо чаще встречаться

Да, похоже выход - в очистке кеша.
Ибо админ сайта или заходит на свой сайт регулярно или сайт, оставшись без присмотра, сдыхает. Потому - почему бы и не почистить.

Спасибо. Я многое понял.

Никто не заставляет вас

Никто не заставляет вас чистить кэш руками. Можно же написать пару строчек в скрипте и поставить это в крон, чтобы чистка происходила автоматически.

можно

можно. только я еще не разобрался как сделать так, чтобы хрон запускался сам, и его не надо было бы запускать вручную. Сейчас получается, что смысла в хроне нет никакого - он не хочет работать как хрон. его надо все время запускать.
c cron разобрался - настройки на хостинге и правильный chmod на файл хрона друпала.

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

т.е. в итоге: есть ли модуль или инструмент для чистки в друпале Всего ненужного (типа как в mediawiki DeleteOldRevisions с удалением несущ страниц, правок, записей о правках и тп.)?

Системный журнал будет

Системный журнал будет чистится сам, если вы в его настройках укажете сколько дней хранить в нём записи.

Модуля для чистки всего ненужного нет, потому что нет самого ненужного :) Всё может кому-либо пригодиться.