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

и еще проблемно для восприятия выглядит hc_header и hc_answer_header
что будет если оба будут иметь значение?
можно б использовать hc_request_header и hc_answer_header- и не запутаешься и не пропадает информация о заголовке запроса
в свете того что нужно сравнить заголовок с исходным чтобы отразить это в мониторе это потребует каких-то затрат
но сравним их с затратами на исполнение сотен регэкспов- это ничто
взять даже заголовок 3 кБ что встретишь крайне редко (обычно до 1 кБ)
команда сравнения двух массивов типа CMPS ассемблера выполнится за столь ничтожное время что не успеет сработать даже один регэксп
а вот забыть присвоить переменной hc_header_replace значение это очень просто
да и просто ее наличие это дополнительная обуза
и неадекватно если заголовок не трогать, изменить hc_header_replace а монитор напишет что заголовок менялся

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

это бета
факта еще ни одного нет, все в руках создателя,можно и нужно пробовать все
если евыявляются неудобства почему бы не принять это в расчет и не ликвидировать их при наличии кворума
вопрос не высосан из пальца- я реально забываю присваивать эту переменную
если hc_header_replace сейчас отменить то это реально не повлияет работу сущесьвующих скриптов
ну как сгущены- это очень сильно бросается в глаза мгновенная загрузка раньше и неспешная постепенная сейчас
не знаю может на какихто супер быстрых и незагруженных сетях это не так но на моем 100 мБит просто крах надежд интерсно увидеть еще отзывы о новой версии при использовании с сетевым кэшем, в форуме не смог увидеть?
пришлось с новой версией убирать дополнительный кэш и менять конфигурацию
мог бы и оставить старую версию но новые скрипты много хорошего дают
уже сам написал пару и доволен
те неудобства о которых писал с ними будет сталкиваться каждый
не хочу навязывать мнение но оно есть такое после начала реальной практики писания скриптов
если у остальных противоположные взгляды нестрашно я думаю может быть не безразличен любой взгляд со стороны

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

еще прошу можно сделать чтобы не обязательно вводить e-mail при отправке поста
это типа hc_header_replace дополнительная и по моим ощущениям ненужная забота для юзвера

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

не удобно получается вставлять заголовки потому что hc_header оканчивается на \r\n\r\n
если сделать оканчивающийся на один \r\n то можно легко писать hc_header = hc_header .. "my header: my value\r\n"

такого быть не может
это просто так принял автор программы и мне кажется будет удобнее это чуть подправить
"должен" я не говорю думаю что уместно сказать "лучше", "удобнее пользователю" не только мне лично
оцени наглядность и удобство одного и второго
сравни также еще затраты (правда это мелочи)
мне вот интересно несет ли какой-то практический смысл передача hc_header сс двумя \r\n на конце? если этио для чего-то задумывалось то интересно услышать для чего а если просто так и никому не нужно то лучше так не передавать
не вижу случаи когда это может понадобится но если вдруг понадобится сделаю именно так
пока все также- никак
жду в этом разделе обещали помочь

спасибо большое что зарегистрили!

после заголовка должна быть но какое отношение это имеет к самому заголовку?
gsub- каждый раз будет делаться поиск по шаблону, раздвижка строки и вставка
..- а так просто конкатенация
передаваться и приниматься программой юудет строка на 2 байт меньшая, все операции с ней в любом скрипте будут на 2 символа короче
отсюда и затрат меньше
нет только ради простоты
если нет разницы в итоге, почему не делать проще?

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

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

---

А если сжат, то где гарантия, что он в предыдущий раз не грузился через WebWarper, поэтому и был им сжат?!
А если включена опция "Распаковывать gzip/deflate файлы перед записью в кэш", то все файлы в кэше будут не сжаты. Будем все грузить через Toonel без разбора?

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

Прям, как в поговорке: "Смотришь в книгу - видишь фигу!":
Не первый раз уже. Может, стоит внимательнее читать Документацию? 

Хм... Я понимаю, что удобнее было ответить вопросом и причем только на вторую половину моего вопроса, но как все-таки быть со страницами, сжатыми ранее WebWarper-ом?
А что, переменная эта только для тебя создается? И те, кто распаковывает GZIP в кэше, не попадут в группу "избранных"?


Без каких-либо затрат? А выяснение атрибутов файла и типа сжатия с потолка возьмется, что ли?

Добавлено: 29 Сентября 2008, 23:52:43

Да и все равно, скрипты пока не умеют управлять "Внешними проксями".

Не готов к разговору о WebWarper и CProxy. Не пользую. Поэтому рецепта тебе подсказать не могу. Даже не могу сказать, будет ли он отличаться от рецепта для Тунеля.
Хм... Чем-то повеяло почти забытым...
Пусть будут иметься в виду те, кто пользует Тунель и не распаковывает GZip в кэше. Ты думаешь, это буду я один?
А теперь представь себе другую "группу избранных", которым несущественны накладные расходы. И они готовы хоть с каждым запросом читать целиком большой файл, искать в нем запись, дописывать если не нашли и сохранять обратно. И все это непрерывно синхронизируя с остальными желающими равноправного доступа.
Это и так уже делается - читается Content-Type, а значит и все остальное. То, что я предлагаю, можно попробовать реализовать уже сейчас и без всяческих дополнительных затрат.
Это на первых порах можно попробовать перехитрить. А там и штатные средства поспеют.

А сколько пользуют, к римеру, "Не загружать большие файлы", "Ограничить скорость загрузки", "Распаковывать перед записью в кэш" и т.д. и т.п.? Ты уверен, что все до одного пользователи? Или взять скрипт _block_external_links, думаешь, каждый его будет пользовать? Не достаточно ли того, что это будет заведомо многочисленный круг?
Пометить URL как-нибудь безобидно, а потом условным прокси эту пометку найти.