HandyCache форум

Вызывает недопонимание необходимость использования колонки "Обязательный" в списках А и П. В списке П я ей реального применения не нашел. В списке А - только для декодирования нового URL (его, имхо, можно организовать автоматически и полностью средствами НС).
Дайте, плиз, кто может, примеры полезного использования этих колонок.

Посмотри в "Дефолтных списках (http://handycache.ru/component/option,com_smf/Itemid,10/topic,31.msg223/#msg223)"...

DenZzz
Ничего для себя не вынес кроме того, что в списке А первое правило нерабочее. Полезность правила 4 списка "А" и 3 правила списка "П" мне непонятна. Поясни, плиз.

Вполне рабочее!


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

Если я правильно понимаю, оно включает URL-ы, аналогичные URL-ам из следующего правила (url=http). Но при этом %3A, %2F и %3F не декодируются, т.к. относятся к правилу 2. Или не так? Если они не декодируются, то получим заведомо нерабочий URL.
Примерно так и представляю себе исходя из документации, но вот конкретное применение кроме декодирования найти не могу. Поясни, плиз назначение конкретных правила 4 списка "А" и 3 правила списка "П". Или еще какой-нибудь пример.

Так. Это правило приведено для примера и оно задумывалось для URL типа:
http://site.ru/redirect.cgi?go=http://site2.ru



Что тут пояснять? Оба правила подчищают "хвосты", оставшиеся после работы обязательного правила.

Например, в списке "П" правило 3 подчищает конечный "?" после отбрасывания сессий в URL типа:
http://www.site2.ru/forums/index.php?s=edbd593b7fd425cd19b8a711ecb38dea
и при этом не "портит" URL:
http://www.site1.ru/forums/index.php?s=edbd593b7fd425cd19b8a711ecb38dea&t=10516

М-да... Т.е. оно заведомо ненужное? Зачем его включать в дефолтные списки? У меня оно стабильно дает показатель 0 срабатываний. А если б сработало, то наверняка неправильно, т.к. нет декодирования. Имхо, надо его или исключить, или объединить со следующим, сделав (go|url).
Беда в том, что когда мы придумаем еще одно правило на эту тему, то для него неизбежно придется повторять все правила, относящиеся к декодированию.
Предлагаю ввести колонку типа "Декодировать" с чекбоксом. Если отмечено галкой, то заменять в оставшемся URL все знаки %XX на их символьное представление.
Это правило (для сессий) можно составить так, чтоб подчищать ничего не приходилось, чему есть наглядный пример в списках NapA.
Просто имеется ощущение, что колонка "Обязательный" применяется только для декодирования. Если это так, то ее надо, имхо, вовсе убрать.

PS В правиле для сессий судя по всему содержится ошибка: ?<= надобно заменить на ?=

Ты об этом:
True#~#(\?|&)(phpsessid|s(id)?)=[^&]{5,}$|(\?|&)(phpsessid|s(id)?)=[^&]{5,}&#~#\4#~#True#~#True#~#0

Именно из-за его "наглядных" повторов внутри одного правила я и разбил его на 2 более коротких:
True#~#(?<=[?&])(session(_sid)?|(phpses)?s(id)?)=[-a-f\d]{7,}($|&)#~##~#False#~#True#~#0
True#~#[?&]$#~##~#False#~#False#~#0
которые охватывают гораздо больше вариантов обозначений сессий!


Ты ошибаешься! В твоей редакции это правило вообще не сможет работать!

DenZzz
Да, я сразу подумал про возможность другой реализации (см. ниже) и лишь потом увидел, что у тебя по-другому.
В твоем случае точно так же можно легко обойтись одним правилом:
#5#~#True#~#(?=[?&]((session(_sid)?|(phpses)?s(id)?)=[-a-f\d]{7,}))(.\1$|(.)\1&)#~#\7#~#False#~#True

Ну да не об этом. А о том, что в переадресации может быть намного более одного правила, вытаскивающего из URL редирект. Практически каждое из них требует перекодирования этого нового URL. Чтоб делать это сейчас, необходимо сразу за каждым таким правилом писать раскодирующие правила, которые:
- не гарантируют полноты раскодирования (всего не упомнишь)
- занимают много места
- требуют дублирования в полном объеме после каждого основного правила.
Стоит, имхо, подумать над необходимостью добавления в ТуДу "Пришить колонку чекбоксов "Декодировать" в списке А". Можно возложить эту головную боль на НС.
А практическая полезность колонки "Обязательный" в списке П так и остается для меня сомнительной. ???

Можно декодирующие правила написать один раз в конце списка!

В качестве необязательных?

Да, хоть как! Чтобы каждый URL не прогонять, можно выше поставить обязательное правило с проверкой наличия "%"...

Не понял тебя. Приведи пример.

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

А можно, например, сделать их необязательными и выше поставить одно обязательное правило, которое будет срабатывать на наличие в URL кодов символов ("%") - тогда нижеидущие необязательные правила будут проверяться только для URL с кодами.

2 DenZZZ
Так прямо нельзя - испортятся URL в параметрах.
Разве что декодировать только ДО знака вопроса

Как напишешь правило, так будет! Надо до знака вопроса - укажи это в правиле!
Значит, твои правила будут начинаться как-то так: ^[^?]+%

2 DenZZZ
Не так просто. Поскольку параметры (они все после знака вопроса) терять нельзя - знак вопроса придется учитывать и в каждом декодирующем правиле. Отсюда простой вывод - декодирующие правила не универсальны и в нынешней реализации использованы верно.

Очень просто! Например, вот такое простенькое обязательное правило в конце списка:
#5#~#True#~#%2f(?=.*\?)#~#/#~#True#~#True
преобразует все "%2f" до знака "?", а после него не трогает!

2 DenZZZ
Правильно :) Только чисто редиректорный вариант (там знак вопроса можно не учитывать) - проще, меньше, эффективнее. Чем мне и нравится.

Кирилл

Вернемся к первому посту топика - тебе лично нужна колонка "Обязательный" или нет?

Я считаю ее очень полезной.

DenZzz
Все равно не пойму, чем это поможет.
Пусть у меня несколько обязательных правил в списке "Переадресация":
[?&]go=http заменять на http
[?&]url=http заменять на http
redirect\.php\?.*http заменять на http
site\.ru/goto/\?\w+:r= заменять на site.ru (здесь адрес относительный, например site.ru/goto/?45:%2fla-la-la%2f)
После замены каждого из них мне надо декодировать кучу символов (%3a, %2f, ... еще много всяких других), иначе вновь полученный URL будет нерабочим. Кроме того надо предварительно отсечь все следующие за URL разделители ; и &.
Сейчас для этого надо записать массу "необязательных" правил и повторить всю их совокупность после каждого из "обязательных" правил.
Если правила декодирования сделать "обязательными", как ты предлагаешь, тогда декодирование будет происходить всегда, а не только в необходимых случаях, что приведет к появлению нерабочих URL.

Первый пост топика не ставит такого вопроса на голосование. Я прошу привести реальные примеры использования этой колонки для того, чтобы она стала нужна и мне. Т.е. примеры Необязательных правил, которые нельзя получить, используя только обязательные. А заодно задуматься, как проще реализовать декодирование.

Можно реальный пример рабочего URL, который правило #5#~#True#~#%2f(?=.*\?)#~#/#~#True#~#True и аналогичные сделает нерабочим?

Нельзя. Я не заметил, что речь идет о декодировании до знака вопроса. :pardon: Правило/подход хорошие. Есть ли примеры использования НЕобязательных правил?

Их есть у меня! :ok:

Где-то в конце списка ставим обязательное правило, которое только определяет, надо ли в URL что-то декодировать:
#5#~#True#~#%(?=.*\?)#~#\0#~#False#~#True
А следом уже удет строй декодирующих НЕобязательных правил:
#5#~#True#~#%2f(?=.*\?)#~#/#~#True#~#False
#5#~#True#~#%3a(?=.*\?)#~#:#~#True#~#False
и т.д.

Таким образом, "строй" декодирующих НЕобязательных правил будет проверяться только тогда, когда в URL есть, что декодировать.
Теоретически, это сэкономит ресурсы системы...

Практически тоже.
Получилось, что на новом витке возвращаюсь к тому же вопросу. Если декодировать такие URL-ы будет сам НС (допустим, галка "декодировать" при правиле списка "Переадресация"). Останется ли применение НЕобязательным правилам? А в списке "Преобразование URL" есть примеры применения (не принимая во внимание те, где правило можно составить и без их использования)?

Поясните, пожалуйста, что означает "Заменить все" и "Обязательный" в разделах "Переадресация" и "Преобразование URL". В FAQ-е ответа не нашел.

Я не понимаю, если я поставил галочку "Разрешить" на против записи, то почему без галочки в "Обязательный" не хочет выполняться. :( Поэтому и задаю вопрос, для чего те все галочки. Чтобы понять :)

Спасибо.

Плохо искал:
- ФАК: Как работает список "Переадресация"? (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ16)
- ФАК: Как работает список "Преобразование URL" во вкладке "Кэш"? (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ17)

Мда... ну я и ступил....
Спасибо.

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

1. В поле "правило" ввожу: +*site.ru*
2. В поле "замена" ввожу: folder
3. Ставлю галку в поле "обязательный". (Кстати для чего галка "заменить все"?)

После этого открываю сайт, открываю папку "cache", а там вместо папки с менем сайта появляется файл с именем сайта. Что я делаю не так?

Как это не  написано?
http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,1/#FAQ16

Цитата из хелпа: "Также можно сделать так, что нужный URL будет храниться в кэше в определенной папке с заданным вами именем."
Где продолжение? Нету!

Убери "звезду" в конце правила! И на будущее - тестируй свои правила в "Тренажере"!

Это следует понимать так: мы можем влиять на то, в какую подпапку кэша сохраняются файлы. Делается это путем модификации URL перед преобразованием его в путь на диске. Какого продолжения тебе не хватает?

Здравствуйте!
Никак не пойму по какому принципу в мониторе пишется о срабатывании списка Преобразования URL при переадресации и когда нет. Объясните пожалуйста, в факе не нашел

Изначально в мониторе писалось

25.09.2008/11:11:41 local/127.0.0.1 http://download.comodo.com//cfp//download//updates//release//cfpinfo.ini 161 161/269 100% 505 "302 Moved Temporarily" П.56, З.1
П.56 (Преобразование URL): \.(?=download\.comodo\.com/)  
З.1 (Запись в кэш): .

При добавлении в Преобразование URL правила
#5#~#True#~#(?<!:|%3a)//+#~#/#~#True#~#True
в мониторе стало писать

25.09.2008/11:24:38 local/127.0.0.1 http://download.comodo.com//cfp//download//updates//release//cfpinfo.ini 161 161/269 100% 555 "302 Moved Temporarily" П.49, З.1
П.49 (Преобразование URL): (?<!:|%3a)//+  
З.1 (Запись в кэш): .


А еще хочется в мониторе различать какой запрос действительно пытается связаться с сервером а какой только ждет очереди и не виноват в повисании. Пусть во втором случае будет вместо земного шара с лупой другой значок. Или в колонке Ответ будет писаться что НС сейчас делает "определение IP...", "соединение с сервером...", "2 попытка соединения с сервером...", "ожидание очереди..."

Список "Преобразование URL" - особенный. Он используется каждый раз при обращении к кэшу. При переадресации (код ответа 301 или 302) список "Преобразование URL" проверяется не только по URL запроса, но по URL из заголовка "Location", на который производится переадресация. Это нужно для защиты от зацикливания.


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

У-у-у... Вот оно как...Спасибо. То есть в строке монитора с переадресуемым запросом будет и запись о срабатывание списка Преобразование URL на другом адресе?

...Все равно не складывается в уме. Видно не допонял все таки. В примере выше сработало П.56 наверно на адресе в поле Location. Почему во втором примере оно не срабатывало?

mai62
Это скорее всего ошибка программы. Исправьте, пожалуйста. А то с толку сбивает

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

luongo
Выложи свой файл URLToCache.lst.

Вот он приложил в zip-архив
Кстати давно хочу узнать, для чего правила
True#~#"#~#%22#~#True#~#True#~#2
True#~#<#~#%3C#~#True#~#True#~#8
True#~#>#~#%3E#~#True#~#True#~#8

См. здесь... (http://handycache.ru/component/option,com_smf/Itemid,10/topic,69.0/)

luongo
Михаил
Мне приходится гадать, что именно вы подразумеваете, когда говорите про ошибку. Вероятно то, что в первом случае правило П56 работало, а во втором нет.
Я не вижу никаких оснований разделить вашу точку зрения. Вовсе не обязательно правило П56 должно было сработать при второй попытке потому, что на момент второй попытки поменялся кэш, поменялся состав правил. Плюс к этому я заметил, что сервер не всегда в поле Location отдает один и тот же URL.
Не знаю что там у вас, но у меня картина следующая: до включения П49 в кэше был только заголовок переадресации и НС обрабатывая его использовал правило П56. Когда я включил правило П49 в кэше рядом с заголовком переадресации появился сам ini-файл. Когда есть возможность работать на выбор с самим файлом или его заголовком переадресации НС выбирает сам файл. Поэтому проверки поля Location уже нет и не срабатывает П56.

Поставил уже последнюю версию, но и со старыми было тоже самое.
На некоторых сайтах, я не знаю точно с чем это связанно, но некоторые сайты грузятся как матрёшки. Я не углублялся, может это из-за iframe. Хорошо, когда они грузятся на один уровень в глубину, а часто бывает до бесконечности. Когда отключаю прокси в навигаторе, проблемма уходит, всё открывается нормально, как должно.

Например: зайдите на: winehq.org
в поисковой строке произведите поиск чего угодно.

Я вложил копии экрана.
hc.jpg - через handycache
nohc.jpg - напрямую, без handycache

(http://hc.jpg)

Подскажите, может это ошибка в программе?, или настройка, которую я упустил?, я перепробовал много разных настроек в handycache, результат всегда один.

У меня после поиска страница нормально выглядит. Смотри в мониторе в колонке Правила какие правила срабатывают при загрузке этой страницы и пробуй их выключать.

У меня тоже нормально. Подозреваю, что проблема у тебя из-за неправильных правил в списке "Переадресация" или "Преобразование URL". Попробуй поставить свежие дефолтные списки.

Спасибо, отключение некоторых правил переадресации помогло.

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

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

Доброго всем здравия и хорошего настроения!


Сколько раз заглядывал в FAQ, так и не смог ни разу однозначно осмыслить приведенный "алгоритм" работы:



1. Опишите пожалуйста более точно алгоритм, а то с такой формулировки масса предположений о последовательности его действий. Можно так же на примерах следующих списков:
  а) 3 обязательных, 3 не обязательных, 3 обязательных, 3 необязательных;
  б) 3 не обязательных, 3 обязательных, 3 не обязательных, 3 обязательных.


2. Как должен выглядеть список, если я хочу, чтобы у меня производились следующие замены:
  а) стандартные комплексные дефолтные замены HC;
  б) группа замен типа p48.radikal.ru/ --> radikal.ru/p48/ (и десятка 2 аналогичных, т.е. в каждом случае срабатывает один из них);
  в) при этом позаменять помимо этих замен всякие спецсимволы по моему усмотрению.


3. Стандартный список замен (откройте изображение в отдельном окне, а то она 800 px в ширину):
http://s55.radikal.ru/i149/0910/58/70a3b6c06006.png (http://s55.radikal.ru/i149/0910/58/70a3b6c06006.png)

(http://s55.radikal.ru/i149/0910/58/70a3b6c06006.png)

Разве последние 3 правила не должны быть НЕ обязательными? Или же поясните, почему они обязательны, т.е. НЕ сработают, если сработает одно из предыдущих правил?

Это способ группировки правил. Необязательные правила привязаны к предыдущему обязательному. Если оно не срабатывает, то следующие за ним необязательные правила пропускаются.


Проверяются первые три обязательные. Если срабатывает третье обязательное, то проверяются следующие три необязательных, иначе они пропускаются. Дальше проверяются следующие три обязательных. Если срабатывает третье обязательное, то проверяются следующие три необязательных, иначе они пропускаются.


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


Не понял ребус. Будет набор обязательных и возможно необязательных правил в зависимости от сложности преобразований.


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

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

А то из фразы "Как только сработало хотя бы одно правило, работают все правила без признака "Обязательный" до следующего "Обязательного" или конца списка." не ясно, что ВСЕ - это только лишь те, которые находятся между сработавшим и следующим обязательным.

Спасибо ))

Не подскажете, как сделать, что бы домены с одинаковыми названиями,
но с разными зонами , для примера yandex.ru и yandex.ua были в одной папке yandex.ru

И домены vk.com и vkontakte.ru в одной папке vkontakte.ru

Заранее благодарю

Аналогичный вопрос обсуждался здесь http://handycache.ru/forum/index.php?topic=337.msg33770#msg33770