Предлагаю не выделять скрипты как "государство в государстве", а встроить работу с ними в общую логику работы с программой:
- скрипты вызывать из соответствующих списков. Например, правило списка "Не обновлять" *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. Будет хорошо?

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

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

Что делать, ограничивается лишь фантазией.
Примеры:
- после успешной скачки сообщить об этом кому-либо (визуально, звуком, e-mail'ом и т.п.), передать скачанный файл куда-либо;
- значимые события (заблокировано/нет, взято из кэша/нет/сколько и др.) на лету фиксировать независимым обработчиком статистики, способным представлять информацию в любых разрезах;
- выяснив, что для файла запрещена запись в кэш, удалить его из кэша, если он там есть (своего рода автоматический сбор мусора);
- если файл не попадает под Ч, Т, Н и нет соединения, то выдать файл из кэша автоматически либо спрося пользователя...

Это функции даунлодера. Не уверен, что это нужно для прокси.


Помню была такая тема: "Интерфейс передачи активности монитора", но что-то быстро ее инициатор потерял интерес к воплощению этой идеи.


Это можно реализовать и из скриптов Ответов, только понадобятся соответствующие расширения функциональности.

Добавлено: 09 Августа 2008, 19:31:30


Я на Серверы-посредники горячую клавишу повесил, но дифференцированно отключать скрипты так не получится - только все сразу.

Хорошо бы сделать опцию: "Распространять горячие клавиши списков на действия скриптов"...

Пока не включаюсь в обсуждение этой проблемы, хочу сосредоточиться на ftp.

Перекрывать/отменять действие списка "Серверы-посредники". Переключать серверы-посредники и внешние прокси в зависимости от иных условий, нежели совпадение URL (пользователь, время суток и др.);
- хочется, к примеру, для ответа 403 выдавать ответ типа нынешнего, но на великом и могучем;
- для разных пользователей/сайтов могут быть разные объяснения, почему они блокированы;
- может не хотеться использовать коды 430 и 431. К примеру, если ниже НС стоит Сквид, то это приводит к заполонению лога Сквида предупреждениями о нестандартном коде ответа. На этом фоне выделить действительно полезную информацию в логе тяжело.
В подобных ситуациях "Показывать файл" бессилен.
Например, добавить распознавание по сигнатурам тех типов файлов, которые сейчас НС не распознает. Или перед переадресацией в определенных случаях делать паузу с выводом пояснения/подтверждения. Или добавить заголовок: Age, Date, Expires, Via, Vary, Warning для информирования клиента. Или скрыть, что ответ дает HandyCache...

Гм... Мне казалось, что из перечисленного ничего эффективно реализовать сейчас не получится. Как это эффективно сделать сейчас по каждому из пунктов?

Под эффективностью имею в виду недопущение выполнения лишних действий. К примеру, что бы мы ни хотели сделать с серверами-посредниками или внешними прокси, делать это нужно лишь после того как принято решение о скачке из интернета. Или дополнительное распознавание по сигнатурам должно включаться только после принятия решения о взятии из кэша.
Не получится. Все списки Ч, П, А переносить в скрипты не будем.
А здесь для изменения заголовка ответа при взятии файла из кэша мы бессильны что-либо сделать R-скриптом.

К сожалению, это не так. В большинстве ситуаций при взятии файла из кэша мне не надо полностью с нуля формировать весь заголовок ответа, мучительно продумывая и создавая в нем все необходимые поля. Пусть это делает НС. Нужно лишь добавить или убрать что-то одно оттуда. Например, убрать Server: HandyCache в ответе 200 From cache (HC) или добавить Expires в ответ 304 Not Modified (HC) и т.п. Я уж не говорю о случаях типа когда ответ в кэше запакован, а клиент не понимает gzip. И совсем плохо, что в попытке сделать как ты пишешь, списки Т и Н тоже придется полностью перемещать в скрипты, что не может даже рассматриваться.

5. Можно сделать, чтобы каждый раз не описывать функцию main (так сказать, в порядке уменьшения лишних телодвижений для пользователя). Если она жизненно нужна для НС, НС вполне может сам автоматически обрамлять скрипт
function main()
...
end
Преимуществом будет и то, что все описанные пользователем функции будут локальными и потенциально не смогут мешать одноименным функциям остальных скриптов.

пытаюсь осваивать скррипты
непойму если hc_answer_header задать значение а hc_answer_body нет- будет мой заголовок и "родное" тело?
и если сделать наоборот- будет мое тело при родлном заголовке?
хелп сделан так что не дает этот ответ
расскажите пжалста
и пжалста еще- зачем задумано присваивать hc_header_replace почему просто не изменить hc_header?

не вижу
пользуюсь HC_Lua_scripts.html
других более подробных справок не нашел дайте ссылок
сравнение с начальным заголовком?
почему бы ничего не сравнивая посылать hc_header- измененный или нет неважно

Неважным это выглядит на первый взгляд. Если НС станет всегда манипулировать с заголовком даже если это и не нужно (а изменение заголовка не самая частая операция при использовании скриптов), это приведет к лишней нагрузке на машину (операции со строками являются относительно ресурсоемкими, они требуют выделения памяти, копирования содержимого с места на место).

4water
По поводу оправданности наличия переменной hc_header_replace не вижу особого смысла продолжать спор вот по какой причине. Доводы в пользу наличия или отсутствия этой переменной можно приводить долго, но не думаю, что одна из сторон сможет победить за явным преимуществом. Обсуждать этот вопрос имело бы смысл до того как НС в данной версии стал публичным. А на сегодня наличие переменной hc_header_replace стало фактом и для изменения этого положения должны быть веские причины.
Согласен - проблема существует. Хотя краски в какой-то мере тобой сгущены. НС читает кэш, но не перед каждым вызовом скрипта, а только если на данный момент информация о нужном файле у него отсутствует. Однажды получив эту информацию (а она бывает нужна не только перед вызовом скрипта, но также при работе со списками и другими опциями), НС сохраняет ее в RAM-кэше и в дальнейшем берет ее оттуда.
В данном случае я буду благодарен тебе или кому угодно за хорошие предложения по смягчению проблемы.
В любом случае тебе спасибо за аргументированную критику.

Пожалуй, единственно возможное решение проблемы - это уже обсуждаемое ранее индексирование кэша, которое позволит существенно снизить количество обращений к диску. Но обратная сторона медали - трудности для любителей ручного добавления/удаления файлов в кэш, хотя польза от индекса все равно перевешивает в плане повышения производительности и расширения функциональности HandyCache в будущем!


Зарегистрируйся на форуме и этой проблемы не будет! Кроме того, скоро эта тема будет присоединена к параллельной: "Предложения по работе скриптов" в разделе "Новые предложения". Гостем ты писать там вообще не сможешь.

Вообще-то это требование стандарта. Только не говори, что HC должен удалить двойной \r\n , а потом его опять вставить, чтобы тебе было проще писать скрипты...


Сделай в скрипте замену: "\r\n\r\n" на "\r\nmy header: my value\r\n\r\n" - если так надо в конец добавить:
   string.gsub(hc_header, "\r\n\r\n", "\r\nMy header: my value\r\n\r\n", 1)

Вообще, можешь свои заголовки хоть сразу после первой строки вставлять.


P.S. А что там у тебя с регистрацией на форуме? Долго эта тема в Гостевом разделе жить не будет...

Чего не может? RFC2616 почитай! После последнего заголовка должна быть пустая строка, иначе сервер будет ждать продолжения запроса.


Лично мне без разницы! Скрипт пишется раз, а потом сам работает и внимания более не требует.
Затраты меньше сейчас, т.к. HC не надо лишний раз вырезать \r\n , а потом опять его добавлять.


А вставлять именно в конец - это что жизненная необходимость такая? Какая разница?

Например, для реализации предложения из ToDo:
Для исключения потерь времени при использовании в качестве родительского сжимающего сервиса типа WebWarper, Toonel, Cproxy добавить возможность создания условного родительского прокси, реагирующего на наличие/отсутствие на странице GZip-сжатия
Если файл в кэше не сжат, то запрос отправить, например, на Toonel или WebWarper.

да я и не был против этого
во всех букварях по lua пишется что по умолчанию переменные равны nil
в скриптах так не будет дошел до этого собственным опытом в справке этого не было
пост написал для того чтобы поделиться с другими- чтоб не делались ошибки
можно и в справке это указать
а минусов этого вобще ни одного не вижу

Хм... Ты думаешь, я как администратор не знаю, включена ли у меня такая опция или нет?
Могу тоже подкинуть "если...". К примеру, что если этот файл захотят читать/менять одновременно несколько скриптов/потоков? Что если файл вырастет до сказочных размеров?
У такого подхода существенный недостаток - затратность.
То, что предлагаю, будет как часы и без каких-либо затрат работать как минимум с Тунелем.

правду говорят дурной пример заразителен
посмотрел я на тебя убеждавшего что там есть то чего нет- и тоже перестал тщательно справку читать
можешь смело обнулить счетчик

А сколько вас? Кто считал? Не нужно опять возвращаться к аргументам типа: "Так лучше всем, я знаю!"...


Я так понимаю, что этот камень в огород Проксомитрона...


Каким образом "перехитрить"?

Их могут пользовать ВСЕ, кто изъявит такое желание, а не только те, кто входит в какую-то ограниченную группу по каким-то там критериям! А у твоего предложения пользователи WebWarper и "распаковывающие кэш" - уже в пролете. Уверен, найдутся еще "изгои"...


Зачем делать для какого-то заведомо ограниченного круга, когда можно сделать сразу для всех?!

При подходе Проксомитрона не обязательно открывать файл-список отдельно каждым потоком и пытаться каждый раз сохранять его на диск! Можно же один раз загрузить список в память, там его обрабатывать и временами сохранять на диск или выгружать за ненадобностью. В Проксомитроне эта проблема как-то решена. И у HC в Серверах-посредниках сейчас успешно работают файл-списки, практически не вызывая тормозов. Можно даже БД какую-нибудь прикрутить для ускорения обработки.

Добавлено: 30 Сентября 2008, 11:12:55

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

нужно проверять размер файла перед загрузкой, и если размер больше, чем оставшийся лимит - не загружать файл

А если обрубить или заморозить скорость, то при отсутствии возможности докачки, весь смысл может потеряться.
В твоём случае - идеальный вариант - внешний шейпер (присмотрись к BWMeter).

ну, это уже отдельная тема, и HC тут как бы не при чём. В BWMeter-е создаются свои пользователи (по ip и mac-адресам) и фильтры для них, которые уже и ограничивают время/трафик/скорость конкретного юзера. 

Мы раньше уже обсуждали, что отдельный файл-список для рассматриваемой задачи бесперспективен. Перспективно общее хранилище метаданных, где в том числе будут отметки о сжатии. Но эта перспектива далека. Здесь же информация о сжатии файла кэша уже лежит "в крамане" НС.
mai62
Сделай, плиз, переменную, где хранилось бы, сжат файл в кэше или нет.

Предлагаю также обсудить, не свести ли все переменные в одну таблицу с именем "hc" и добавить туда методов. Пусть будут переменные hc.answer.body, hc.action, hc.request.body, hc.request.header, hc.answer.header и т.п. Методы могут быть типа hc.answer.GetHeaderField(field_name), hc.request.SetHeaderField(field_name), hc.URLToCache(url) и любые другие. Весь предоставляемый НС API будет, таким образом, собран компактно в одном модуле и получит единообразное оформление.

Надо доработать обработку заголовков, чтобы не только url обрабатывался, а все поля заголовка http.
Это можно сделать тремя путями
1. пишешь $URL(регулярное выражение)|$DATE $CHARSET(....)....&100<#size<500....
2. пишешь типа Browser=регулярное выражение host=регулярное выражение....
2. Добавить несколько колонок с полями заголовка http и поле с лоческой операцией между полями заголовка
Только когда используются первые два пути еще надо добавть toolbar со списком магических слов, что бы незапоминать их.

Это делается в темную, из содержимого окон приложения про скрипты ничего не узнаешь.
Это жe windowsное приложение, поэтому все действия должны быть видны из окон.
Иначе лучше тот же самый squid использовать, у него алгоритмы буферезации получше будут, всетаки в американском институте разрабатывали:)
В нем тоже внешние скрипты не вслепую используются.
Хотя тоже могли бы одну могучую строку с сылкой на внешний файл в начале написать и все.

HC пишет в своем мониторе о срабатывании скриптов! В следующей версии можно будет из скрипта выдать любой текст в Монитор и лог.

а вот то что обрезано и что на самом деле идет сразу за привиденой цитатой
'The HTTP/1.1 support is still incomplete with an internal HTTP/1.0 hop, but should work with most clients. The main   HTTP/1.1 features missing due to this is forwarding of requests using chunked transfer encoding (results in 411) and forwarding of 1xx responses (silently dropped)'
протокол http1.1 с СЕРВЕРОМ сквид НЕ поддерживает вовсе
с ним не добиться пайплайна сквид может лишь разделить входящий пайплайновый запрос и запрашивать их у сервера параллельно, натыкается при этом на ограничение сервера на число одновременных соединений с одним ip и жуть тормозит, ожидая разрешения сервера.
с ним не получить сжатую страницу например rambler.ru - через сквид из интернета идет 67кб через нс 21 кб. на каждой странице рамблера сквид по сравнению с нс накрутит 20-50кб моего трафика. вот и американские институты

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

1. Экономия места на диске при сегодняшних размерах винтов и ценах на них - это крайне несущественная проблема. Тем более, что маленькие файлы (примерно до 700 байт) NTFS хранит прямо в MFT и лишнее место на диске не занимает!
2. Кэш HC при желании точно также можно хранить в контейнере на виртуальном диске - в ФАКе описано, как это сделать.
3. Сомневаюсь, что Сквид со своими контейнерами работает быстрее, чем HC c кэшем на NTFS.


И что это показатель качества? С каких пор?! Все значимые изобретения в Америке были сделаны иностранными эмигрантами, в т.ч. из СССР...


Вообще-то, HC использует стороннюю библиотеку регулярных выражений PCRE и вносить в нее изменения мы не имеем права - это нарушение авторских прав! А вот в скриптах каждый сам себе автор.


У-гу, я давно предлагаю убрать все дублирующие функции из GUI... 


Регулярным выражениям по функциональность до скриптов - как до Луны. Устанешь дорабатывать...


HC тоже!