Предлагаю не выделять скрипты как "государство в государстве", а встроить работу с ними в общую логику работы с программой:
- скрипты вызывать из соответствующих списков. Например, правило списка "Не обновлять" *in:dont_update_file_by_size ^handycache\.ru вызовет соответствующий скрипт обработки ответа для УРЛов офсайта. Если ни к какому другому списку скрипт не относится, включать его в "Серверы-посредники";
- hc_action и lua.lst убрать;
- переменную hc_header_replace заменить на script_fired - признак того, считается или нет скрипт сработавшим (по умолчанию false).

Правила и скрипты - это обработчики HTTP-сообщений. Их сущность одинакова. Скрипты могут обрабатывать те же элементы сообщений, что и правила (УРЛ) и плюс к этому другие заголовки. В добавок скрипты могут делать еще чего-нибудь но опять же в привязке к обработке сообщений. С точки зрения их функцинирования, правила - частный случай скриптов. По сути, правила - это более удобная для пользователя запись скриптов определенного вида. Точно так же как запись правила с "+" - это более простая запись регэкспов определенного вида.
Есть общие глобальные категории действий с HTTP-сообщениями, которые лежат в основе логики работы НС: блокировать, не обновлять, писать в кэш, запрещать все это,... Имхо, логичным было бы, чтоб все, что относится к одной категории, находилось в одном месте.
Блокировка по УРЛ находится в списке Ч, блокировка по Content-Length в настройках, а по Content-Type или AnswerCode в Серверах-посредниках и во внешних файлах. Проще (пользователю), имхо, было б когда бы они находились в одном разделе, описывающем все случаи блокирования.
Точно так же по другим категориям. К примеру, не обновлять по УРЛ сейчас находим в списке Н, а не обновлять по Content-Length - в скрипте во внешнем файле, управление которым находится в серверах-посредниках.
Кстати, я за то еще, чтоб скрипты жили не в отдельных внешних файлах, а в тех же файлах, что и нынешние списки. В правиле даже не надо для них специальной лексики создавать (о которой я писал постом выше типа *in:dont_update_file_by_size ^handycache\.ru). В строке правила можно придумать маленькую кнопочку, нажав которую раскрывался б любой указанный в настройках редактор (например, Блокнот или встроенный) с возможностью правки содержимого.
А что при описанном раскладе может содержать hc_actiоn?

Давно именно это и предлагаю. Но эта тема не об этом.
Хм... Какое правило невозможно повторить скриптом? Ответ - нет такого правила. Тогда в чем же смысл этих правил как не в предоставлении намного более удобной для пользователя формы обработки?
Ошибаешься. Список полностью закрыт возможным набором значений переменной hc_action.

Это ж здорово, что скриптами можно делать что-то еще. Я вроде и не возражал против этого. Просто это "что-то еще" я пока отнес к hc_action="пусто". Волнует та часть скриптов, которая будет находиться в общей и без того немеряной куче и делать при этом операции (блокировать и др.), являющиеся основными в логике программы и уже имеющие свое средоточие в интерфейсе.
Как быть, когда у пользователя 100 скриптов? У каждого из этих ста свое имя файла на английском языке. Получится ли комфортно плыть в таком море? Будет скрипт, блокирующий такие-то УРЛы для пользователей таких-то, блокирующий такой-то Content-Type для пользователя такого-то, при запросе таких-то УРЛ блокирующий и подающий звуковой сигнал, блокирующий... Все это будут блокирующие скрипты в общей куче скриптов. Не проще ли пользователю их видеть и править в Черном списке? Список перестанет быть привязанным только к регэкспам, а будет сосредоточивать весь спектр условий, необходимых для реализации конкретной основной функции прокси-сервера (в данном случае, блокировки).

Мне тоже не нравится эта идея. Один скрипт в зависимости от заголовков может выдавать совершенно разные действия, поэтому отнести его к какому-то одному списку нельзя. К примеру, скрипт save_or_block_403_and_404.lua выдает "save" или "stop" и поэтому в равной степени его можно отнести и к списку "З", и к списку "Ч". Если еще убрать hc_action, то такой скрипт вообще не сможет работать!

И в большинстве случаев получим лишнюю двойную работу по проверке одних и тех же заголовков/условий в случае, когда "stop" в списке Ч не сработал! Это эффективно?


Как уже упоминалось ранее, затраты ресурсов/времени на обработку скриптов мизерны...


Внеси в нужные скрипты проверку на то, что переменной hc_action еще не было присвоено определенное действие. Как, например, я сделал в скрипте block_long_file.lua.


Не сложнее, чем разобраться в сотне правил. Можно сгруппировать скрипты по их назначению. Да и вообще, не представляю, зачем нужна сотня скриптов и почему нельзя проверку схожих условий сделать в одном скрипте.


Можно ввести в скриптах какую-нибудь новую переменную, скажем, hc_stop_script, при присвоении которой значения "true" прекращать обработку следующих скриптов. Только нужно ли это...

На самом деле немножко не о том спорите. Регексп - это тоже скрипт на соответствующем языке.
И вызывать скрипты из правил в принципе неплохо. Но наверно имеет смысл сильно упростить формат вызова
Т.е. в поле "правило" вместо регекспа пишем <префикс>файл:функция, функция должна вернуть true/false (сработал/не сработал), акция определяется списком откуда вызван.
При вызове из непреобразующих списков (т.е. всех кроме "преобразования" и "переадресации") глобальные переменные - только на чтение.

В точности об этом и говорю. Разница в деталях - предлагал не заморачиваться с файлами, а держать весь скрипт прям в списке.
Отличная новость. Особенно про hc_answer_body.
Имхо, стоит. Только не переполох устраивать, а продумывать загодя, не допуская сваливания всего в трудноразгребаемую кучу и не забывая за расширением функциональности про вопросы эффективности программы, а также дружелюбности и простоты ее общения с пользователем и внутренней логической стройности.
Представь, что нынешние списки мы сольем в файл rules.lst. Будет хорошо?

Если ты читал предыдущие посты, то знаешь, что этого не получится. И что эффективность ниже сейчас.
Можно выносить предварительно на обсуждение: "Хочу сделать так-то. Давайте помыслим, как это будет лучше". А сейчас да, я представляю, что не хочется что-то переделывать и одно это обеспечивает негативный угол зрения на предложения по изменению. Аргументы просто отбрасываются и все.
Утрируя, могу провести параллель (без обид), что проще всего дать пользователю С++ и пусть он сам все пишет. Гибкость максимальная, эффект большой, автору делать вообще ничего не надо. Только достаточно ли этих двух вещей для наслаждения пользования программой? Для меня - нет. Иначе я бы юзал сквид.

Тут еще подумалось. Может быть желание исполнить какое-то действие только после того как стало известно, что файл, например, не блокируется или что он, например, точно пишется в кэш, после того как он полностью загружен из сети и т.п. Имхо, полезно было б иметь и другие точки вхождения для скриптов, не только нынешние две. Это, пожалуй, сможет быть равносильным введению плагинной системы.