Этот документ содержит список часто задаваемых вопросов и ответов на них, связанных с программой WWWOFFLE версии 2.6. Не все вопросы были реально заданы пользователем, некоторые из них предназначены для того, чтобы дать больше информации людям, пробующим использовать программу, если им недостаточно информации из файла README.
Секция 0 - Почему здесь нет ответа на мой вопрос?
Секция 1 - Что програма делает (и что - нет)
В 1.1 WWWOFFLE поддерживает http, ftp, finger, https, gopher, ...?
В 1.2 WWWOFFLE работает на других системах кроме UNIX?
В 1.3 Можно ли изменить WWWOFFLE так, чтобы в генерируемых страницах ...?
Секция 2 - Как использовать WWWOFFLE в интранет
В 2.1 Можно ли получить доступ к прокси серверу WWWOFFLE с других компьютеров, а не локально?
В 2.2 Почему удаленные клиенты не имеют доступа к WWWOFFLE?
В 2.3 Почему удаленные клиенты не могут переходить по всем ссылкам?
В 2.4 Какие есть проблемы при многопользовательской работе?
В 2.5 Как я могу сопоставить разные конфигурации разным группам пользователей?
Секция 3 - Что смотреть, если WWWOFFLE не работает
В 3.1 Почему броузер показывает пустую страницу, когда использует WWWOFFLE как прокси?
В 3.2 Почему WWWOFFLE не находит хост, а броузер без прокси - находит?
В 3.3 Почему мой броузер говорит "Соединение прервано сервером"?
В 3.4 Почему при переходе по ссылке на FTP сайт попадаю на другой сервер?
В 3.5 Почему WWWOFFLE не корректно обрабатывает Cookie?
В 3.6 Почему WWWOFFLE перезапрашивает страницы, просмотренные, когда не было связи?
В 3.7 Почему WWWOFFLE не дает доступа к некоторым защищенным паролем страницам?
В 4.1 Почему мой броузер не запускает апплет XYZ?
В 4.2 Поддерживается ли имя апплета в уникоде?
В 4.3 Почему мой броузер Нетскейп выдает сообщения о trustProxy безопасности?
Секция 5 - Как максимально использовать возможности WWWOFFLE
В 5.2 Как я могу сделать рекурсивную загрузку с заданной переодичностью?
В 5.3 Как предотвратить просмотр пользователями указателя?
В 5.4 Как я могу использовать JunkBuster с WWWOFFLE?
В 5.5 Как я могу улучшить производительность WWWOFFLE?
Секция 6 - Дополнительная информация о WWWOFFLE
В 6.1 Кто написал WWWOFFLE, Когда и Почему?
В 6.2 Какие почтовые рассылки есть для WWWOFFLE?
В 6.3 Как я могу сообщить об ошибках в WWWOFFLE?
Этот документ выпускается с каждой новой версией программы WWWOFFLE, т. е. если вы читаете ВиО для данной версии и, если ваш вопрос часто задаваемый о новой версии, то по определению здесь ответ не найдете. Эти Вопросы-И-Ответы с дополнительной информацией о программе также доступны на домашней странице WWWOFFLE. http://www.gedanken.demon.co.uk/wwwoffle/version-2.6/
Некоторые из этих протоколов поддерживаются, а некоторые - нет.
http : Да
Первая версия программы WWWOFFLE поддерживала только http.
ftp : Да
Начиная с версии 2.0 введена поддержка ftp.
finger : Да
Начиная с версии 2.1 введена поддержка finger. Хотя это и не
стандарный протокол для организации прокси-сервера, это не причина,
что бы такая возможность не была сделана.
https : Да
Начиная с версии 2.4 есть поддержка прозрачного представительства (proxying)
SSL (Secure Socket Layer) соединений. Это включает https протокол.
gopher : Нет
Этот протокол в настоящее время менее популярен, чем WWW.
Посмотрев на броузеры, поддерживающие этот протокол, можно сказать,
что его применение возможно, но спрос на это выглядит ограниченным.
Например, DOS / Win3 / Win95 / WinNT / OS/2.
UNIX = Да
Это система, для которой программа спроектирована и изначально
написана, она должна работать на многих версиях UNIX.
Я знаю, что она работает на Linux, SunOS 4.1.x, Solaris 2.x, *BSD.
DOS/Win3 = Нет
Программа разрабатываль не для DOS, используемые имена файлов и
многопоточная природа программы не позволяют этого.
Win95/Win98/WinNT = Да (Частично)
32-битная версия программы для Windows теперь доступна благодаря
комплекту разработчика Cygwin, который предоставляет библиотеку
системных вызовов UNIX в среде MS Windows.
OS/2 = Может быть
Я не знаю эквивалента Cygwin для OS/2, если он существует, то
возможно будет портировать также, как и для Windows95 / Windows NT.
Этот вопрос задают многие. Люди хотят видеть Javascript, картинки, цветовое оформление ... на веб-страницах, которые генерирует WWWOFFLE. В версии 2.2 и последущих выпусках есть возможность подстраивать под себя все веб-страницы, генерируемые программой. Это значит, например, что цвет фона и размер шрифта могут быть изменены по вашему вкусу. Узнать, как это сделать, можно прочитав файл README в каталоге /var/spool/wwwoffle/html/messages.
Да, можно, это свойство изначально присутствует в программе. Другие клиенты,подключенные к серверу с работающей программой wwwoffled, могут быть любого вида. Требуется только наличие сетевого доступа к серверу, и клиенты должны иметь броузеры, настроенные на доступ через прокси WWWOFFLE.
По умолчанию содержимое wwwoffle.conf не разрешает доступ к прокси-серверу
никаких клиентов, кроме localhost. Разрешить им доступ можно отредактировав
файл wwwoffle.conf как описано ниже и загрузив новую конфигурацию.
Секция AllowedConnect конфигурационного файла сожержит список хостов, которые
могут соединяться с прокси-сервером WWWOFFLE. Эти имена сравниваются с
именем, которое WWWOFFLE получает при соединении, и доступ либо разрешается,
либо запрещается. В этом списке могут использоваться шаблоны, при этом допол-
нительного DNS-разрешения имен не производиться.
Например, вы используете частный диапазон IP адресов 192.168.*.* для вашей
локальной сети, тогда секция AllowedConnect в конфигурационном файле должна
выглядеть так.
AllowedConnect
{
192.168.*
}
Это позволит всем хостам с IP адресами из данного диапазода соединяться
с прокси-сервером WWWOFFLE.
Некоторые ссылки, генерируемые в веб-страницах, выходящие за пределы прокси
WWWOFFLE, должны указывать на другие страницы на прокси-сервере. Для выполне-
ния этого нужно имя хоста, исполняющего программу WWWOFFLE, указать в секции
LocalHost конфигурационного файла.
Например, если компьютер, исполняющий программу WWWOFFLE, называется www-proxy,
то секция LocalHost в конфигурационном файле должна выглядеть так.
LocalHost
{
www-proxy
localhost
127.0.0.1
}
Первое имя то, которое WWWOFFLE использует для генерации этих ссылок. Другие
используются для обозначения серверов, которые не будут кешироваться прокси-
сервером.
Безопасность - это свойство программы, которое я обдумывал на всем протяжении написания WWWOFFLE, хотя это и не самая большая моя забота. Что получилось - смотрите ниже. Для Win32 версии нужно заметить, что на Win95/98 нет уровня безопасности пользователя, который предоставляет UNIX. Поэтому невозможно создать файлы, которые бы были доступны WWWOFFLE и не доступны всем остальным пользователям. Возможности безопасносности, присутствующие в WWWOFFLE, неприменимы в таких системах. Пароль конфигурационного файла Этот файл имеет пароль, указанный в секции StartUp, который используется для ограничения доступа к управляющим функциям WWWOFFLE. Если установлен, то он должен использоваться, чтобы перевести WWWOFFLE в режим "когда есть связь", перевести в режим "когда нет связи", очистить кеш, остановить сервер, отредактировать конфигурационный файл и т. д. Если вы установили пароль, то также надо сделать файл доступным для чтения только владельцу файла. Пароль пересылается как обычный текст, когда программа wwwoffle используется для управления сервером wwwoffled. Шифрование, используемое для аутентификации веб-страниц, примитивное. Прокси аутентификация С возможностью управления доступом к WWWOFFLE используя протокол HTTP/1.1 метод прокси аутентификации добавляется проблема с безопасностью. Она основана том же, что и для пароля конфигурационного файла; имя пользователя и пароль хранится в конфигурационном файле как обычный текст и передается по сети с использованием того же примитивного протокола шифрования. uid/gid сервера WWWOFFLE uid и gid процесса сервера wwwoffled может быть задан параметрами run-uid и run-gid в секции StartUp конфигурационного файла. Эти uid/gid нужны для получения прав чтения конфигурационного файла (запись не требуется, если не используется интерактивная страница редактирования) и чтения/записи буферного каталога. Если эти параметры используются, то сервер должен запускаться пользователем root. Удаление запрошенных URL Только пользователь, сделавший запрос страницы, может удалить этот запрос, и только когда удаление делается сразу после запроса. Это потому, что пароль получаеется путем хеширования содержимого файла в каталоге исходя- щего. Это означает, что доступ для чтения этого каталога болжен быть для всех запрещен в целях безопасности. Встроенный веб-сервер Это очень простой сервер и он переходит по символическим ссылкам, в целях безопасности только файлы, доступные всем для чтения, могут быть запрошены. Они также должны быть в каталоге, который сервер wwwoffled может прочитать. A check is not made for each directory component so world readable files in a directory readable only by the uid that runs wwwoffled are not safe. Доступ к кешу В общем случае нет проблем при разрешенном доступе к кешу, предоставленному в режиме только чтения (но смотрите "URL с паролем"). Только есть одна особенность - очистка кеша с использованием времени доступа к файлам испортится запуском grep на кеше. URL с паролем URL, которые используют имя пользователя и пароль, нужно сохранять в кеше. Для простоты они ни как не скрываются. Это значит, что некоторый URL, ис- пользующий имя/пароль может быть показан в журнальном файле (только с Debug или ExtraDebug уровнями). Файлы в кеше также содержат информацию об имеи и пароле, поэтому они должны быть недоступны для пользователей. Доступ к серверу Доступ к серверу WWWOFFLE на прокси порт 8080 ограничен IP адресами и именами хостов, перечисленными в секции AllowedConnectHosts конфигурацион- ного файла. По умолчанию установленно разрешение доступа только для localhost. Любой другой хост не указанный в списке не имеет доступа к серверу, но соединения от них будут приняты и проверены на правильность до того, как в соединении будет отказано. Это может использоваться для организации DoS атаки так, что неавторизованные хосты могут держать WWWOFFLE в занятом состоянии, и правильные соединения будут отвергнуты. Если вы используете ядро Линукса версии 2.2 (2.4 отличается), то утилита ipchains может быть использована для запрета доступа к портам прокси- сервера (смотри в ipchains HOWTO замечания по компиляции ядра). Следующие две команды предотвратят доступ с любого другого хоста, кроме localhost, используйте их внимательно! /sbin/ipchains -A input -i lo --dport 8080:8081 -p tcp -j ACCEPT /sbin/ipchains -A input --dport 8080:8081 -p tcp -j DENY -l
Когда есть две группы пользоватлей, которые будут обращаться к одному и тому
же кешу WWWOFFLE, но каждая группа имеет разные конфигурации WWWOFFLE, нужно
запустить два экземпляра WWWOFFLE.
Например, в школе может понадобиться так, что ученики имеют доступ к кешу,
но не могут запросить новые страницы. Учетелям должен быть предоставлен
доступ к тому же кешу и разрешено использовать WWWOFFLE в режиме, когда есть
связь, и запрашивать новые страницы, когда нет связи.
Два конфигурационных файла WWWOFFLE будут одинаковы во многих отношениях,
но будут отличаться, как показано ниже.
-- wwwoffle.student.conf -- -- wwwoffle.teacher.conf --
StartUp | StartUp
{ | {
http-port = 8080 | http-port = 9080
wwwoffle-port = 8081 | wwwoffle-port = 9081
password = secret | password = teacher
} | }
|
OfflineOptions | OfflineOptions
{ | {
<*://*/*> dont-request = yes |
} | }
|
AllowedConnectUsers | AllowedConnectUsers
{ | {
| teacher1:password1
| teacher2:password2
} | }
|
AllowedConnectHosts | AllowedConnectHosts
{ | {
| teacher1pc
| teacher2pc
} | }
Две копии WWWOFFLE должны использовать разные номера портов. Они используют
один и тот же буферный каталог и, следовательно, одни и те же веб-страницы
доступны обоим группам пользователей. Вам понадобиться иметь пароль на учени-
ческой версии WWWOFFLE для предотвращения редактирования конфигурационного
файла, а для учительской версии он может и не понадобиться. Нужно оградить
учительский WWWOFFLE от использования учениками используя секции
AllowedConnectHosts и AllowedConnectUsers в конфигурационном файле. Это огра-
ничит набор машин, с которых возожен доступ, или потребует ввода имени и пароля
до начала работы.
В приведенном выше примере ученикам запрешено запрашивать любые страницы,
когда нет связи. Этот экземпляр WWWOFFLE никогда не используется, когда есть
связь, и у учеников нет возможности работать с WWW, когда есть связь. Только
учительская версия WWWOFFLE используется в режиме, когда есть связь.
При посещения веб-страницы ничего не возвращается, если используется WWWOFFLE в качестве прокси-сервера, но когда сайт запрашивается напрямую без WWWOFFLE, то страница отображается. Для этого есть несколько причин (обо всех мне сообщили или обнаружил сам): а) Веб-сервер, к которому вы обращаететсь, требует заголовок User-Agent. Если он отсутствует или установлен в не распространенное значение (не Netscape или IE), то возвращается пустая страница. В этом случае, если у вас задано в секции CensorHeader конфигурационного файла удаление заголовка User-Agent, то придется это убрать или установить замену заголовка на строку, которая принимается сервером. б) Как выше, за исключением того, что возвращается не пустая страница. Решение тоже кроме того, что может использоваться любая строка для User-Agent. в) Веб-сервер использует cookies для сохранения состояния. Это обычный способ для сайтов, ориентированых на формы, чем на содержание, и часто об этом не предупреждают. г) Броузер и сервер пытаются использовать расширения HTTP/1.1, которые WWWOFFLE игнорирует.
Наиболее вероятная причина в том, что DNS сервер, заданный, когда WWWOFFLE был запущен, в дальнейшем не может использоваться. Это может случиться, например, если файл /etc/resolv.conf был изменен после запуска wwwoffled. Это не только проблема WWWOFFLE, но и любой (большинство) другой программы, когда конфигурация DNS меняется во время их работы. Когда WWWOFFLE определяет IP адрес, он использует стандартную библиотечную (libc) UNIX функцию - gethostbyname(). Часть libc, определяющая адрес по имени (называющаяся разрешающей библиотекой), инициализируется, когда программа первый раз использует ее функцию. Когда функция разрешающей библиотеки будет исполняться позже, она использует конфигурацию, бывшую при первом вызове функции. Исменение DNS конфигурации может произойти без вашего ведома. Некоторые дружественные пользователю программы настройки PPP изменяют файл /etc/resolv.conf в зависимости от провайдера доступа к интеренет, к которому вы подсоединились. Один из примеров программ, которые делают это, - kppp. Большинство проектов броузеров (особенно Netscape) могут использовать другие методы определения адреса по имени отличные от метода стандартной библиотеки. Это значит, что они могут продолжать работать даже, если конфигурация DNS изме- нилась после их запуска. Работающий Netscape и не работающий WWWOFFLE озна- чают, что ваша конфигурация сервера имен изменилась и это не ошибка в WWWOFFLE. Из-за этого часто предлагают изменить WWWOFFLE так, что бы он вызывал функцию res_init() каждый раз, когда переходит в режим, когда есть связь. Это функция, вызываемая всеми програмами при первом обращении к DNS. Она инициализирует библиотеку разрешения имен DNS. Мои возражения против этого следующие. Невозможно сказать, что вызов res_init() более одного раза безопасен для всех систем, что вызов res_init() более одного раза работает на всех системах или, что вызов res_init() более одного раза будет работать в будущих версиях библиотеки разрешения. Функция res_init() очень низкоуровневая функция в библиотеке разрешения, она не предназначена для такого использования. Она предназначена для инициализации библиотеки разрешения, везде, где я только ни смотрел, не сказано, что вызов этой функции более одного раза безопасен, или, что она может использо- ваться для изменения метода разрешения DNS имен. Одно решение - это запустить локальный сервер имен. Пакет bind содержит стан- дартный сервер имен, но есть и альтернативные. Один из них - pnsd, который является кеширущим DNS-сервером. Независимо от вашего выбора нужно сделать localhost сервером имен и менять конфигурацию сервера имен каждый раз, когда устанавливается новое соединение.
Это случается, когда используется Netscape для доступа к некоторым веб-страни- цам. Причина неизвестна, но проблема наблюдается только когда используется WWWOFFLE и отсутствет при прямом соединении.
Если каталог называется '/dir' на ftp сервере и вы загружаете страницу 'ftp://server/', то получаете список каталога, в котором есть ссылка на '/dir'. Переход по этой ссылке должен перевести броузер на 'ftp://server/dir/', но некоторые броузеры вместо этого перейдут на 'ftp://dir/'. Я думаю, что такое поведение - это вина броузера, а не WWWOFFLE. Если зашли на 'http://server/' и далее проследовали по ссылке '/dir/', то следует ожидать перехода на 'http://server/dir/', а не на 'http://dir/'. И это вполне справедливо. Почему поведение броузера для ftp и http отличется для ftp и http, я не знаю. [Это должно быть исправлено в версии 2.1 WWWOFFLE, так, что это не применимо в данной версии ВиО]
Нормальные прокси-серверы не могут кешировать результат URL, который был запрошен с cookie потому, что результат отличается для каждого пользователя. WWWOFFLE будет кешировать страницы, которые имеют в себе cookie потому, что он предназначен для снижения сетевого трафика. Если вы хотите использовать cookie при просмотре, то некоторые страницы, которые вы увидите, не могут считаться правильми, когда смотрите их в режиме отсутствия связи. Лучший путь это учесть, поместить конкретный сайт, посеща- емый вами, в секцию DontCache конфигурационного файла. В WWWOFFLE невозможно кешировать страницы, которые используют Cookie, управляя содержимым тем же способом, что и при обработке старниц, не использующих cookie. Требуется некоторая реализация обработки cookie для того, чтобы давать разные ответы пользователям в зависимости от cookie, содержащемся в запросе. Это должно означать, что будут кешироваться разные страницы для одного и того же URL. Но остается проблема, что переход на страницу А установит cookie и затем при переходе на страницу Б получим другую страницу. Так, например, если вы имеете cookie и кешированную страницу Б, когда нет связи, переход по ссылке с Б к А может дать новый cookie от А (когда установите связь и загрузите А). Это значит, что теперь вы не можете вернуться к странице Б, когда нет связи, т. к. cookie уже отличается от прежнего (и страница тоже, но она у вас еще не кеширована). Еще худшая проблема в том, что перезагрузка страницы В с одним и тем же cookie каждый раз даст вам разные страницы. Это потому, что cookie используется для подсчета количества ваших посещний страницы. Нет способов обнаружить это и поэтому у вас сохранится одна и та же полученая страница В (однажды кеширован- ная) даже, если должны были бы получить разные.
Когда нет связи и просматриваются страницы через WWWOFFLE, случается что, страницы снова перезапрашиваются, хотя они уже есть в кеше WWWOFFLE. Есть две возможные причины этого, известные мне. 1) Когда выбираются закладки в записной книге Netscape (и возможно других броузеров), делается новый запрос для записаной в книге страницы. 2) Некоторые пользователи сообщают, что когда используется Netscape, все просматриваемые страницы запрашиваются заново. (Не все пользователи замети- ли такое поведение, и нет видимой причины, почему одни люди встречают это, а другие - нет.) В обоих этих случаях броузер передает запрос, который говорит WWWOFFLE, что требуется новая версия страницы. Это то же, что и средство принудительного обновления, которое предлагает большинство броузеров. Заголовок передается с запросом, который говорит прокси-серверам между броузером и сервером, что требуется новая версия страницы, а кешированная версия должна быть проигно- рирована. Для запрещения такого действия в WWWOFFLE есть параметр, называемый 'pragma-no-cache', который по умолчанию равен 'yes'. Когда этот параметр установлен, запросы обновленных версий страниц будут выполняться как требуется. Присвоение параметру значения 'no' остановит такое двойное поведение, которое было описано выше.
Когда броузер запрашивает страницу, которая требует задания имени пользователя и пароля, они определяются в диалоге между броузером и сервером для предоставления правильной страницы. 1) Когда броузер впервые запрашивает страницу, защищенную паролем, нормальный запрос передается без пароля в нем. Это очевидно, поскольку нет возможности сразу узнать, какая страница имеет пароль. 2) Когда сервер принимает запрос страницы, требующей аутентификации, осутствую- щей в данном запросе, он отсылает назад ответ '401 Unauthorized'. Он содер- жит "область", которая определяет диапазон страниц, которые тре- буют правильные имя и пароль. Область не достаточно хорошо определена, она может быть некоторым набором страниц на том же сервере, there is no requirement for them to be related, although they normally are. 3) Когда броузер получает ответ '401', он спрашивает пользователя об имени и пароле, если они еще не были указаны для данной области. Если они уже известны броузеру, то нет нужды заново спрашивать пользователя. 4) Запрос, посылаемый броузером назад, теперь в заголовке содержит имя пользо- вателя и пароль, а все остальное в запросе как в (1). 5) Теперь сервер передаст назад запрошенную страницу. WWWOFFLE имеет свойство, которое упрощает эту процедуру для пользоватля. Многие броузеры, например, переходят сразу к шагу 4, если они знают, что требуется задать пароль для одной из страниц на сервере. Это значит, что, если пользо- ватель хочет посмотреть защищенную паролем страницу, когда нет связи, то в кеше WWWOFFLE нет ничего, что бы сказало броузеру о необходимости имени и пароля. Только после запоминания вернувшегося на шаге 2 результата WWWOFFLE может иметь дополнительную информацию, которая принудит броузер спросить пользователя. Когда страница запрошена и заданы имя и пароль, WWWOFFLE сначала запросит страницу без имени и пароля. Это соответствует шагу 1 из списка выше и не является не правильным даже, если броузер хотел другого. Если страница не тре- бует пароль, то версия без пароля будет возвращена броузеру. Если пароль необходим, то WWWOFFLE сделает второй запрос с именем пользователя и паролем и передаст этот результат броузеру. Некоторые серверы применяют это и дальше, они ожидают от пользователя переда- чи пароля для каждой страницы. Если запрос передан без пароля, то броузер перенаправляется на страницу регистрации. Особое поведение WWWOFFLE, описанное выше, не работает в этой ситуации. Для запрета этого свойства WWWOFFLE предусмотрен параметр 'try-without-password', который по умолчанию равен 'yes'. Когда этот параметр установлен, запросы страниц с паролями заставят WWWOFFLE сделать запрос без пароля. Установка этого параметра в 'no' остановит такое поведение WWWOFFLE, описанное выше.
[Walter Pfannenmueller <pfn@online.de> пишет:] Я полагаю, что вы разрешили поддержку java. Ваш броузер сказал что-то вроде "Не могу запустить Апплет XYZ.class". Проверьте, что файл был успешно загружен WWWOFFLE. Если файл доступен, откройте консоль java (ваш броузер должен предоставлять что-то подобное) и получите по-больше подробностей о проблеме. Возможно это нарушение безопасности. Каждый броузер имеет свой класс SecurityManager и вы должны обратиться к инструкции, как можно снизить эти ограничения. Однако, если ваш апплет хочет вступить в контакт с неким серверным сервисом (servlets, RMI, CORBA), то мы исчерпали все возможности офлайного (когда не связи) чтения.
[Walter Pfannenmueller <pfn@online.de> пишет:] Я не знаю. Я заменяю такие имена на UTF8 кодированные, а также можно основы- ваться на том, что ваша файловая система или хостовая файловая система сделает с ними. Компиляторы Java создают проблемы с уникодом, даже не смотря на то, что он должен поддерживаться. Я приму любую информацию, которая поможет осветить это темное место. Буду рад узнать, как закодировать преобразование уникода в UTF8. Реализация в javaclass.c выглядит как-то неуклюже.
[Walter Pfannenmueller <pfn@online.de> пишет:]
Должно быть сообщение об ошибке
Не могу определить IP-адрес хоста ... Смотрите свойство trustProxy.
(Could not resolve IP for host ... See the trustProxy property.)
Броузер Netscape пытается проверить IP-адрес хоста - источника апплета.
Пока нет связи, это невозможно. Поэтому вам надо убедить броузер доверять
проки-серверу. Для этого вам надо найти файл preferences.js под UNIX или
prefs.js под Windows. Отредактируйте этот файл даже, если в нем говорится
"не редактировать" и вставьте где-нибудь строку
user_pref("security.lower_java_network_security_by_trusting_proxies", true);
Убедитесь, что закрыли все окна броузера потому, что
файл настроек будет перезаписан при закрытии программы. Это должно работать
для всех Netscape 4.0x и 4.5.
Дополнительную информацию можно найти на
http://developer.netscape.com/docs/technote/security/sectn3.html
Наиболее легкий способ - это перейти на страницу списка наблюдаемых страниц и упоря- дочить страницы по "Времени доступа" (http://localhost:8080/index/monitor/?atime). К каждой странице происходит обращение в процессе наблюдения, так недавно проверенные будут располагаться в начале этого списка.
Это комбинация возможностей рекурсивной загрузки и наблюдения. Если вы выбрали нужную страницу в списке рекурсивной загрузки (http://localhost:8080/refresh-options/) с желаемыми параметрами, нажмите кнопку, которая выведет страницу, на которой сказано, что запрос был записан. Здесь есть ссылка, позволяющая следить за данным запросом, она переведет вас на обычную страницу наблюдения (http://localhost:8080/monitor-options), а поле URL будет уже заполнено.
Доступ к указателям может быть запрещен пользователям, используя секцию DontGet
в конфигурационном файле.
DontGet
{
http://localhost:8080/index
}
Вы должны удостовериться, что имя хоста, указанное первым в секции LocalHost,
совпадает с тем, которое будет задано в DontGet.
Internet Junk Buster - это программа, которая отфильтровывает ненужную рекламу и излишества веб-страниц. В самые последние версии WWWOFFLE добавлены многие возможности, такие же как и у программы JunkBuster, но не все. Если вы посмотрите на параметры, которые имеет WWWOFFLE, то, возможно, решите, что не нужно использовать JunkBuster. Если вы решите использовать обе программы, то есть два варианта: 1) Броузер <-> WWWOFFLE <-> JunkBuster <-> Интернет Любые запрошенные пользователем страницы, которые JunkBuster блокировал, будут иметь в кеше WWWOFFLE сообщения об ошибке. Рекурсивная загрузка или загрузка изображений, которые WWWOFFLE делает в фоновом режиме, передаются через JunkBuster и сообщения JunkBuster об ошибке кешируютя. 2) Броузер <-> JunkBuster <-> WWWOFFLE <-> Интернет Любые страницы, запрошенные пользователем, которые JunkBuster блокировал, не будут запомнены в кеше WWWOFFLE. Рекурсивная загрузка и загрузка изображений, которые делаются WWWOFFLE в фоновом режиме, передаются через JunkBuster и они будут запомнены в кеше WWWOFFLE, но блокируются, когда броузер попытается вывести их. Если вы решите, что WWWOFFLE загружает много потому, что вы используете его для просмотра, когда нет связи, то первый метод предпочтительней. Если вы решите, что будете использовать его только в режиме, когда есть связь, и не будете делать запросы, когда нет связи, то второй метод лучше. Если сокращение трафика наиболее важная функция JunkBuster, то первый вариант лучше, поскольку он предотвратит загрузку WWWOFFLE не нужные страницы.
В зависимости от того, что вы хотите улучшить в WWWOFFLE, есть несколько
изменений, которые могут привести к улучшению производительности.
1) Если вы хотите, чтобы WWWOFFLE обрабатывал кешированные страницы быстрее.
Программе нужно запоминать кешированные веб-страницы на диске. Это главная
деталь, которой можно заняться для улучшения производительности и быстроты
исполнения.
Первое направление попыток - это увеличение производительности физического диска,
используемого для кеша. Это может означать несколько вещей: наибыстрейший диск,
использование раздела на отдельном диске, не имеющем сильно загрущенных разделов
или подключение диска к IDE контроллеру, который не разделяется с другими дисками.
Затем, вы можете попытаться улучшить производительность аппаратных интерфейсов
операционной системы. Это может быть как выбор правильного драйвера для
оборудования, так и точная настройка параметров драйвера (например, используя
hdparm на Линуксе).
Другая вещь, которую надо проверить, - это используемая файловая система. Неко-
торые операционные системы позволяют выбирать файловую систему, используемую
для каждого раздела на диске. На Линуксе, например, использование reiserfs
вместо ext2fs должно увеличить производительность за счет более эффективной
обработки больших каталогов. There may
also be options that can be used when the disk is mounted that will improve the
performance.
В Линуксе, например, можно изменить размер буферов ядра, которые используются
для дискового кеширования, сделав следующее:
echo 25 30 75 > /proc/sys/vm/buffermem
echo 10 10 65 > /proc/sys/vm/pagecache
Это увеличивает количество памяти, зарезервированной и максимально доступной
для кеширования файлов.
Другое изменение, которое можно сделать, - это оптимизация конфигурационного
файла. Здесь можно сделать множество вещей, все они имеют тот или иной
недостаток. Уменьшите количество элементов секции DontGet, это сократит время,
затрачиваемое на поиск соответствия с запрашиваемым URL, используйте шаблоны
везде, где можно. Запретите модификацию HTML и анимированных изображений
(секция ModifyHTML). Снизьте максимальный возраст в секции Purge для
уменьшения кеша.
2) Если вы хотите, чтобы WWWOFFLE уменьшал загрузку сети.
Одно из свойств WWWOFFLE, которое привлекает пользователей, - это возможность
снижения загрузки сети. Это может быть сделано несколькими путями, снижая
частоту, с которой запрашивается каждая 'статическая' страница, хранение
большого количества страниц в кеше, блокирование рекламы или игнорирование
запросов сервера сохранить обновленные одинаковые страницы.
Статические страницы, которые могут быть с большой пользой кешированы на протя-
жении большого времени, это изображения. Это могут быть иконки, появляющиеся на
всех страницах одного сервера. Они могут сохраняться в кеше WWWOFFLE долгое
время и нечасто запрашиваться снова, поскольку они редко изменяются. Следующий
пример показывает изменения, которые нужно сделать для снижения трафика для
одного заданного набора статических картинок (эти параметры, зависимые от URL,
нужно поместить до общих параметров в этой секции).
OnlineOptions
{
<http://images*.slashdot.org> request-changed = 4w
<http://*slashdot.org> request-changed-once = yes
}
Purge
{
<http://images*.slashdot.org> age = 6w
<http://*slashdot.org> age = 4w
}
Большее количество страниц может быть сохранено в кеше путем увеличения значения
параметра "age" (возраст) в секции Purge конфигурационного файла. Это может
быть применено ко всем страницам или выборочно к часто посещаемым сайтам.
Секция DontGet конфигурационного файла приносит наибольшую пользу для сокращения
сетевого трафика блокированием элеменов страниц, которые вы не хотите видеть.
Например, это может быть баннерная реклама или счетчики посещений.
Другая способность, которую некоторые веб-серверы сочтут полезной, это прину-
дить броузер отказаться от перезагрузки одной и той же страницы. Это может быть
сделано несколькими путями и есть несколько способов в WWWOFFLE игнорировать
такие запросы. Использование параметра 'request-changed' или 'request-changed-once'
в секции OnlineOptions будет означать, что WWWOFFLE не сделает новые запросы
для кешированных старниц, пока их возраст не достигнет определенного значения.
Параметры 'request-expired' и 'request-no-cache' могут быть установлены в 'no',
в этом случае даже страницы с истекшим сроком годности не будут снова
запрашиваться.
Программа WWWOFFLE была ниписана Андреем М. Бишопом (Andrew M. Bishop) (amb@gedanken.demon.co.uk) в 1996,97,98,99,2000 годах. Во Всемирной Паутине (WWW) есть домашняя страница WWWOFFLE, доступная через авторскую домашнюю страницу на http://www.gedanken.demon.co.uk/ . На ней обновляются новости о программе, когда становятся доступными новые версии. Самая ранняя версия программы того же автора написанная на Perl используется то сих пор, но она была выпущена с ограниченной функциональностью исключительно для малого количества применений. Работа над программой WWWOFFLE была начата в рождественский праздник в 1996 г., изначально как игра с усовершенствованием perl-версии. После выпуска бета-версии 0.9 в начале января 1997 возник большой интерес к программе, который привел к выпуску в том же месяце версии 1.0. Последовали следующие версии вплоть до декабря того же года, когда была выпущена версия 2.0. Она содержала много новых возможностей (такие, как FTP) и включала большую долю переписанного кода, сделавшего ее более легкой для поддержки и сборки, в т. ч. полностью измененный формат кеша. Версия 2.1 была выпущена в марте 1998 года с некоторыми новыми возможностями, версия 2.2 - в июне 1998 с дополни- тельными возможностями и версия 2.3 в августе 1998 с еще бОльшими возможностями. Версия 2.4 имела еще больше возможностей, когда была выпущена в декабре 1998 года и в версии 2.5 в сентябре 1999 были снова добавлены дополнительные возможности. Версия 2.6, вышедшая в ноявре 2000 года, содержит возможность иметь конфигурационные параметры для разных URL. Win32-версия программы стала доступна благодаря версии beta-20 комплекта разработчика Cygwin в конце октября 1998 года, когда вышла версия 2.3е WWWOFFLE. Версии 2.4b и 2.5a так же были выпущены и для Win32, хотя ни одна их них полностью не работает на большинстве платформ из-за несовместимости. С версией 1.1.7 библиотеки cygwin версия 2.6а программы WWWOFFLE работет наиболее успешно. Программу WWWOFFLE можно распространять согласно с терминами GNU General Public License (смотрите файл `COPYING').
Есть три почтовые рассылки, полезные для WWWOFFLE. На них можно подписаться
двумя разными способами - на веб-странице пользователя WWWOFFLE и по электрон-
ной почте.
wwwoffle-announce Для сообщений о новых версиях WWWOFFLE.
wwwoffle-users Для обсуждения свойств WWWOFFLE, за исключением особен-
ностей, специфичных для операционных систем.
Первая рассылка только для сообщений от автора WWWOFFLE, здесь не допускается
никаких дискуссий. Последние две открыты для публикакций от подписчиков рас-
сылки и других, кто не подписан.
Все списки рассылки управляются компьютером с коммутируемым доступом. Это значит,
что будут задержки сообщений, посылаемых в них.
To join one of these mailing lists send an e-mail to one of
wwwoffle-announce-request@gedanken.demon.co.uk or
wwwoffle-user-request@gedanken.demon.co.uk with the subject 'subscribe'.
По e-mail, пошлите их мне на amb@gedanken.demon.co.uk и поместите WWWOFFLE где-нибудь в теме. Вы также можете сообщить об ошибках или предоставить коммен- тарии через обратную связь на домашней странице WWWOFFLE, доступной через http://www.gedanken.demon.co.uk/ . Перед этим, вы должны проверить Вопросы-и-Ответы и веб-страницу WWWOFFLE - нет ли там ответа. Если его нет и вы хотите сообщить это мне, то это поможет, если вы сумеете воспроизвести ошибку, в частности, вам скорее всего понадобится запустить wwwoffled в режиме отладки. Если вы используете sh/bash в качестве оболочки, то запустите wwwoffled -d 5 -c wwwoffle.conf > wwwoffled.log 2>&1 Если вы используете csh/tcsh в качестве оболочки, то запустите wwwoffled -d 5 -c wwwoffle.conf >& wwwoffled.log Если вы хотите еще больше отладочной информации, то используйте '-d 6' вместо '-d 5'.