NAME

 

wp - WebProxy, работает только по протоколу HTTP ( 1.0/1.1 ).


DESCRIPTION

 

Ну в общем кладете его в cgi директорию сервера, подкручиваете пару переменных в скрипте и можно работать. В скрипте ( процедура init() ) необходимо настроить:

TIMEOUT

 

Время ожидания ответа от http сервера. Используется при чтение каждой строки из сокета ( при чтении заголовка ответа сервера ), и при чтении блока данный длинной 4096 байт, тоже с сервера.

MY_PATH

 

Путь исполняемого скрипта ( wp ), в контексте web сервера. По умолчанию берется из $ENV{SCRIPT_NAME}, но на некоторых (h1.ru например) серверах путь другой, поэтому для уверенности можно прописать руками. Например $self->{MY_PATH} = '/cgi-bin/wp'.

MY_URL

 

Полный URL скрипта.

USE_PROXY

 

Использовать этот прокси сервер. Формат : [_USER_:_PSWD_@]_SERVER_[:_PORT_], все, что в квадратных скобках не обязательно, Авторизация может использоваться только Basic... Если не определено то ходим без прокси.

CRLF

 

Символы перевода строки.

USE_NPH

 

Скрипт работает под NPH.

REP_URL_IN

 

Тут лежит список 'слов' после которых в теге надо искать и заменять URL'и.

MAX_POST

 

Максимальный размер данных которые переправляются от клиента к удаленному серверу ( только для метода POST ).

ROLE

 

Правила/права доступа к различным документам. Формат : ссылка на массив ( по сути матрица из трех столбцов, просто не хотелось вводить еще кучу анонимных массивов ) Первый 'столбец' которого шаблоны URL запросов ( синтаксис регулярных выражений perl'а ), второй 'столбец' шаблоны IP адресов ( тоже регулярные выражения Perl'а ), ну и последний правила:

 1 - Доступ разрешен.

 0 - Доступ запрещен.

 Любая строка - новый URL. Т.е. заменяет клиентский запрос
                этим запросом.

После долгих колебаний решено было проверять доступ начиная с шаблона IP...

R_APPEND

 

Тут массив элементов которые дописываются к заголовку HTTP запроса отправляемого на сервер. Здесь можно например заставить выдавать, что нить типа 'User-Agent: my C00l Agent', предварительно вырезав эту строку посредствам HEADER = { HTTP_USER_AGENT => 0 }.

R_HEADER

 

Правила для перенаправления http заголовка клиента. Формат : хеш. Ключи переменные из $ENV, значения ссылка на анонимный массив из 2 элементов.

 1 - Код. Используется для разделения длинных значений заголовка.
          1 - разделять по ','
          2 - разделять по ';'
          0 - не разделять.

Если значение не ссылка на массив, то считается, что данные из этой переменной не следует передавать на сервер...

Также скрипт отрабатывает все переменные $ENV{HTTP_*} явно не указанные в HEADER, используя разделитель ','.

A_APPEND

 

Тут массив элементов которые дописываются к заголовку HTTP ответа отправляемого клиенту.

A_SKIP_HDR

 

Все заголовки которые не желательно передавать клиенту, примерно такой синтаксис : 'Connection|Server'.

A_SAFE_HDR

 

Все заголовки которые вырезаются из документов с типом `text/html', но остаются во всех остальных. Т.е. не желательно например отдавать Accept-Ranges - из за того, что клиент может попросить докачать html-документ, а мы поменяли его размер ( ссылки изменяются ), короче фигня может получится..., а например image/gif мы не трогаем, поэтому там оно как то даже может пригодится.

A_RNM_HDR

 

Заголовки которые надо переименовать в WP-{REAL_NAME}. Так например можно сохранить 'Server' и пр... При совпадении A_RNM_HDR и A_SAFE_HDR и MIME типе данных отличном от 'text/html' переименовываются только те заголовки которые не встретились в A_SAFE_HDR.

Теперь немного про то как все работает: Запрос к http серверу берется из переменной $ENV{PATH_INFO} т.е. допустим скрипт лежит на сервере alisa, его урл http://alisa/cgi-bin/wp , и вы захотели скачать документ http://mail.ru/index.html тогда ваш запрос должен выглядеть так

 'http://alisa/cgi-bin/wp/mail.ru/index.html'

Если хотите передать параметры на mail.ru методом GET ( POST тоже работает только иллюстрировать не удобно... ), то данные передаются как обычно:

 'http://alisa/cgi-bin/wp/mail.ru:80/index.html?from=gosha;to=any'

А это запрос с Basic authorization:

 'http://alisa/cgi-bin/wp/gosha:hi@mail.ru:80/secret_dir/secret_file.html'

Также можно указать порт и пр... При обработке ответа сервера скрипт разбирает ( или пытается, кому как нравится ) его заменяя все ссылки в нем на 'через себя'... Както сумбурно, поэтому лучше сами попробуйте, вот.


NOTES

 

Все переменные начинающиеся с 'A_' - относятся к ответу сервера, с 'R_' - к запросу клиента.

Использовать можно только Basic авторизацию. Только, есть одна не хорошая весчь при использовании такого синтаксиса ( с паролем в смысле ), все ссылки в html документе будут иметь такой же ( .../wp/USER:PSWD@HOST/PATH ) вид. Поэтому если вздумать переходить на другой сайт, которому не нужен пароль, лучше передать новый запрос проксе, только уже без имени/пароля, чтоб не гонять его по сети за зря...

При отключенном NPH запросы http серверу передаются только по протоколу 1.0.

Если хотите чтобы правильно отрабатывался Referer не используйте в запросе броузера алиасы имени машины, на которой установлен скрипт.

Если вы используете ограничение доступа, то порядок отработки правил простой: у кого младше индекс в массиве тот и имеет приоритет. Допустим вы хотите разрешить ходить клиентам с адресами 192.168.1.* куда угодно, а всем остальным только на сервер mail.ru, тогда настройка примерно такая должна быть:

     $self->{ROLE} = [
                        'mail\.ru\/?.*' , '.*',                1,
                        '.*'            , '192\.168\.1\..*',   1,
                        '.*'            , '.*'                 0
                     ];

и желательно протестировать все шаблоны перед использованием... Хотя можно было б все в eval {} загнать, но ленььььь.


BUGS

 

Некорректность отработки некоторых тегов содержащих '>' внутри, например <img alt='>' src=/im1.gif>

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

Ссылки создаваемые JavaScript'ом не отрабатываются...

Могут возникнуть проблемы, при установке данного скрипта на сервер с 'Русским' апачем, данные перекодируются дважды, в результате чего их можно прочитать только после ручной перекодировки. Можно в общем то сделать корректную перекодировку данных, но надо ли... Теоретически должно так работать: в броузере сделать кодировку по умолчанию ту, которая 'родная' для сервера, на котором лежит этот скрипт, но только если сервер на который реально отправляется запрос, тоже умеет нужную кодировку отдавать. В общем Russian Apache IMHO не лучший выбор...

Хотя щас есть патчик ( для версии 1.7 ) который по замыслу должен поправить работу с ru-Apache ( только надо иметь `правильную' iconv и Text::Iconv )... И еще настроить переменные CHARSETS и DEST_CP, где DEST_CP - имя кодировки на сервере ( см. Text::Iconv ), CHARSETS - ссылка на хеш где ключ алиас кодировки, который извлекается из ответа удаленного сервера ( charset=``koi8-R'' ), а значение имя кодировки для модуля Text::Iconv. В патче есть пример описания алиасов для кодировок, вот.


AUTHOR

 

 Okunev Igor V.  mailto:igor@prv.mts-nn.ru
                 http://www.mts-nn.ru/~gosha