» HandyCache ( Часть 5 )

C0USIN

Цитата:

Если файл в кэше есть и он "старый" то не обновлять. Если надо гарантированно обновить - жмем горячую клавишу. Тогда при отправке поста на форуме не придется отключать список Не обновлять

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

---

mai62

Предлагаю сделать так: если перед значением "критерия свежести" стоит "-", то менять действие на противоположное. Т.е. проверяем критерий свежести, как и раньше без "-", но если он просрочен - то НЕ обновляем файл.

Например, -168:00 будет означать: НЕ обновлять файлы, закачанные больше недели назад. Аналогично для даты, например: -01.12.2006

DenZzz
Поддерживаю.

DenZzz

Цитата:

НЕ обновлять файлы, закачанные больше недели назад. Аналогично для даты, например: -01.12.2006

Гениально! Супер! Я обеими руками ЗА!!! ОЧЕНЬ нужная фича!

DenZzz

Цитата:

Предлагаю сделать так: если перед значением "критерия свежести" стоит "-", то менять действие на противоположное. Т.е. проверяем критерий свежести, как и раньше без "-", но если он просрочен - то НЕ обновляем файл.

Сделаю.

Цитата:

Вопрос в следующем - получится ли у меня использовать HC на флешке для того, чтобы он у меня был единственным прокси для всяких portable прог...

Цитата:

novikoff_dmitriy
Никаких проблем. HandyCache хранит все настройки в ini файлах.
Кеширование можно и отключить, но тогда смысл в использовании HC пропадет.
Лучше ProxySwitcher какой нибудь использовать

А как определить через какой прокси пошло соединение, это где-то показывается? Есть ли в НС проверка работоспособности проксей - т.е если один не отвечает, то подключаться к следующему?

novikoff_dmitriy
Индикация есть, автоматической смены нет. Т.к. HC не переключатель проксей а сам является самодостаточной программой.

Нельзя ли анонсировать обновление "Списки HC от NapA"?
Не каждый раз в "шапку" заглядываем...

Заметил вчера, что переадресация выполняется раньше черного списка
Почему так?
В адресной строке некоторых баннеров присутствует подстрока url=http, в результате на место баннера грузится, то что стоит за http, а черный список не срабатывает

Bolenic

Цитата:

Нельзя ли анонсировать обновление "Списки HC от NapA"?

NapA здесь редко появляется... Все анонсы есть у него на сайте.

---

Visman

Цитата:

Заметил вчера, что переадресация выполняется раньше черного списка
Почему так?

Всегда так было. А почему должно быть наоборот? Кому-то надо блокировать уже очищенный от редиректа URL, т.к. в нем может содержаться куча параметров, на который будет постоянно срабатывать Черный список.

Добавь правило для своих хитрых баннеров в Белый список для отмены "Переадресации" или подправь само правило.

Цитата:

Нельзя ли анонсировать обновление "Списки HC от NapA"

Там есть ссылка на RSS

Мне давно хотелось объективно проверить эффективность RAM-кэш, но я не знал какой программой это сделать. Сегодня такая программа нашлась (Process Explorer for Windows v10.21 от Sysinternals). Я провел такой эксперимент: перевел НС в автономный режим и трижды загрузил страницу форума сначала с выключенным RAM-кэш, а потом включенным. Вот результаты моего эксперимента (символом X помечен момент включения RAM-кэш).



P.S. Эксперимент проводился на версии НС, которая только готовится к выходу. В ней работа RAM-кэш оптимизирована. Результаты с версией 0.97b1a могут быть другими.

mai62
Цитата:

на версии НС, которая только готовится

Когда, ориентировочно, можно будет пощупать это?

NothingAnother

Цитата:

Когда, ориентировочно, можно будет пощупать это?

Бог даст - к Новому Году подарочек будет

C0USIN

Цитата:

HC не переключатель проксей а сам является самодостаточной программой

хмм... а что мешает добавить такую функциональность? высокая адаптируемость является лишь плюсом любой самодостаточной программы

novikoff_dmitriy
Такую фичу уже предлагали. Почитай топик. Думаю, лишей она не будет.
Главное продумать алгоритм работы, чтобы автору осталось только реализовать.

А как на счёт регулировки записи в кеш по размеру (например НЕ писать файлы больше 5 мб) и управлением правилами кеширования по заголовку Content-Type?

mai62
Пока не готов плагинный API, нельзя ли реализовать хотя бы замену идущего в запросе User-Agent на произвольное значение по срабатыванию определённого правила? Здесь весьма важный пример применимости такой фичи...
P.S. C0USIN, тебя это особо заинтересует!

N1ke

Цитата:

А как на счёт регулировки записи в кеш по размеру (например НЕ писать файлы больше 5 мб)

Давно реализовано!

Цитата:

управлением правилами кеширования по заголовку Content-Type

В ToDo это есть: "Управление загрузкой с помощью настраиваемых правил для Заголовков".

N1ke
Цитата:

как на счёт регулировки записи в кеш по размеру

Это есть в "Настройки->Управление загрузкой"

Цитата:

управлением правилами кеширования по заголовку Content-Type

mai62 перенёс это для реализации через плагины

DenZzz оказался быстрее

C0USIN

Цитата:

Такую фичу уже предлагали. Почитай топик. Думаю, лишей она не будет.
Главное продумать алгоритм работы, чтобы автору осталось только реализовать.

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

Добавлено:
Нашел в TODO [more=похожую] Добавить возможность для "Условного прокси" создать правило типа "если основной прокси не отвечает" (502 Bad gateway) и может ещё каких-либо ошибок подключения для автоматического перехода на резервный прокси, если основной недоступен. Или не правило, а опцию "Резервный прокси", к которому обращаться при проблемах с основным прокси (условным или безусловным);[/more] заявку, но по-моему мой вариант проще для реализации и шире по охвату возможных случаев

novikoff_dmitriy

Цитата:

по-моему мой вариант проще для реализации и шире по охвату возможных случаев

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

А как быть со списком "Безусловных прокси" - там же может быть задано несколько строк, из которых только 1 включена. Переходить к следующей строке может быть не в интересах пользователя, раз он отключил эту строку. Хотя, это можно регулировать порядком строк либо добавить какой-нибудь чек-бокс для строк, которые будут резервными в случае проблем.

DenZzz
Сразу вопрос - а разве в нормальной ситуации просматриваются все прокси из безусловного списка? Пусть проверяется только отмеченный.
Или дейсвительно добавить галочку "Проверять ВСЕ прокси-серверы", которая будет активироваться, если отметить галочку о проверке.

novikoff_dmitriy

Цитата:

Сразу вопрос - а разве в нормальной ситуации просматриваются все прокси из безусловного списка?

Нет, только 1 активный с галкой напротив.

Цитата:

Пусть проверяется только отмеченный.

Тогда перебор неотвечающих прокси будет возможен только в "Условных прокси".
Хотя, с помощью условия .* из условных прокси можно сделать безусловные...

Только что обнаружил, что при переходе на предыдущуу страницу на форуме Referer заполнен, т.е. например если с этой страницы перейти на предыдущую, то запрос будет такой:

Цитата:

GET http://forum.ru-board.com/topic.cgi?forum=5&topic=21354&start=600 HTTP/1.1
Accept: */*
Referer: http://forum.ru-board.com/topic.cgi?forum=5&topic=21354&start=620

В связи с этим вопрос: можно ли средствами HandyCache "отловить" разницу в меньшую сторону между полями GET и Referer?
Т.е. сравнить содержимое поля Сайт с содержимым поля Правило?

popkov

Цитата:

В связи с этим вопрос: можно ли средствами HandyCache "отловить" разницу в меньшую сторону между полями GET и Referer?

Нет. Сравнение полей и заголовков уже обсуждалось, когда речь шла о "Блокировании внешних объектов". Видимо, это можно будет сделать, когда появится управление заголовками...

Цитата:

Тогда перебор неотвечающих прокси будет возможен только в "Условных прокси".
Хотя, с помощью условия .* из условных прокси можно сделать безусловные...

Этого не совсем понял =/
Отсюда я понял, что:
Цитата:

Если включен список Условных прокси, то сначала проверяется он.
...skipped...
HC начинает проверять список сверху и при срабатывании правила в поле "Условие" трафик пойдет через прокси-сервер, указанный в этой строке.
...skipped...
Если ни одно "Условие" не сработало, то трафик пойдет через прокси, указанный в списке Безусловных прокси (если он включен). Иначе, трафик пойдет, минуя прокси.

Таким образом, если предположить, что галочки реализованы, выходит:
ВАРИАНТ 1 (с учетом условных) (исправленный):
если все галочки сняты, то логика работы с прокси сохраняется;
если отмечена галочка "Проверять прокси-серверы", то логика опять же сохраняется, за исключением того, что при поставленной галке прокси-сервер сначала проверяется на работоспособность - если жив, то все как обычно, иначе забить на него и перейти к проверке следующего в списке(ах).
если отмечены обе галочки: "Проверять прокси-серверы" и "Проверять ВСЕ прокси в обоих списках (и использовать первый рабочий)" (вторая активируется при отмеченной первой, иначе вторая неактивна - серенькая), то: если используется список "Условных проки", то [проверка n-го условного прокси] => ( [проверить условие, если удовлетворяет]=>[проверить жив ли прокси, если жив]=>[использовать], [не жив OR не удовлетворяет]=>[перейти к проверке следующего]),[нет ни одного живого в условных]=>[проверять безусловные и подключиться к первому живому]

ВАРИАНТ 2 (без учета условных) (отброшенный):
Вообще оставить одну галочку "Проверять ВСЕ прокси (и использовать первый рабочий)" применительно только к списку безусловных прокси. Логика, я думаю, понятна - найти первый рабочий прокси-сервер и использовать его. Приоритет выставляется порядком.

ЗЫЖ Во блин, написал то сколько...

mai62
Привет. У меня с Преобразованием URL непонятки.
Есть правило (.*/forum/.*\d)(&st=0)$ и замена /1. Все работает как надо.

Решил поэкспериметировать и укоротил правило до (/forum/.*\d)(&st=0)$. По идее (если я правильно понимаю) результат замены должен быть другим, но он не меняется. Вот что выдает тренажер:
0(19): /forum/index.php?showtopic=6004&st=0
1(19): /forum/index.php?showtopic=6004
2(50): &st=0
--------- После -- замены ----------
zoneofgames.ru/forum/index.php?showtopic=6004

PS: исходный урл - ввв.zoneofgames.ru/forum/index.php?showtopic=6004&st=0
...
...
Проверил в Regex Coach получил тоже самое. Получается, я спокойно могу использовать более короткий вариант?

V0lt
Цитата:

замена /1

Синтаксис предполагает символ "\" а не "/" - обрати внимание, если это не "очепятка"

novikoff_dmitriy

Цитата:

если используется список "Условных проки", то [проверить n-ый условный прокси] => ( [жив]=>[проверить условие, если удовлетворяет]=>[использовать], [не жив]=>[перейти к проверке следующего]),[

Проверять "жив" ли прокси надо ПОСЛЕ проверки условия, иначе будет много пустой работы, если условие все равно не позволит нам его использовать - это лишние затраты времени и трафика!

Цитата:

Вообще оставить одну галочку "Проверять ВСЕ прокси (и использовать первый рабочий)" применительно только к списку безусловных прокси.

Думаю, проверять все строки и даже отключенные - не совсем правильно! В списке могут быть отключенные прокси, которые пользователь использует в очень редких случаях, и ему вовсе не надо, чтобы HC пытался ко всем ним подключиться в случае проблем с другими!

Поэтому я предлагал: либо добавить новый чек-бокс для Безусловных прокси, которые будут резервными в случае проблем; либо вообще не использовать Безусловные прокси в качестве резервных, т.к. можно вполне обойтись одними Условными прокси - компоновкой нужных строк можно легко задать любой порядок перебора прокси для каждого условия и отключать временно ненужные!

---

V0lt

Цитата:

Решил поэкспериметировать и укоротил правило до (/forum/.*\d)(&st=0)$. По идее (если я правильно понимаю) результат замены должен быть другим, но он не меняется.

Не так! Во втором случае заменяется не весь исходный URL, а только та часть, которую захватывает правило!
Т.е. zoneofgames.ru во втором правиле просто не участвует в замене, а переносится из исходного URL в первоначальном виде.

Цитата:

Получается, я спокойно могу использовать более короткий вариант?

Можешь!

DenZzz

Цитата:

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

если честно, мне тоже идея с условными/безусловными проксями не вполне ясна, я тоже считаю, что условных вполне достаточно (но не упоминал об этом, т.к пользователи вероятно привыкли к такому порядку вещей и не хотелось выслушивать нападки от недовольных....)

Цитата:

Проверять "жив" ли прокси надо ПОСЛЕ проверки условия

значит останавливаемся на 1ом варианте в проверкой "живости" после проверки условия...