вторник, сентября 25, 2007

Отладка GWT + CGI скрипт

Так как я недавно окончательно перешёл на linux, то столкнулся с некоторыми проблемами которых не было под Windows... Например под Windows в эклипсе я запросто отлаживал кроссдоменные ajax вызовы. В случае с cgi скриптами они в типичных случаях(если ничего не предпринимать) всегда кроссдоменные в режиме отладки, потому что gwt shell грузится на localhost:8888 а cgi скрипты соответственно лежат где-то ещё. Но т.к. IE (возможно только при определённых настройках - не помню менял ли я там что-то) наплевать на кроссдоменные ajax-вызовы, то под Windows всё это работало замечательно (только предупреждение вроде выскакивало и всё). Да там были другие проблемы (например с кэшом ) но всё работало так или иначе.

Под linux же я получал такой Exception: "The URL http://myhost.ru/script.cgi?param1=1is invalid or violates the same-origin security restriction". Сначала я попытался "хакнуть" firefox чтобы отключить это ограничение, но из этого у меня ничего не вышло - всё равно получал то же самое. Немного переформулировав запрос гуглу я нашёл-таки решение и даже целых два.

Решение первое было такое: поднимаем локально апач по 8889 порту, и проксируем все запросы к cgi скриптам на нужный нам хост(в примере ниже на локалхост на 80 порту) а остальные запросы на gwt shell висящий на 8888 порту локалхоста. Т.е. у меня получился примерно следующий конфиг для виртуального хоста:
<VirtualHost localhost:8889>
ProxyRequests Off
<proxy>
Order deny,allow
Allow from all
</proxy>
#redirect to my cgi application on external server
ProxyPass /cgi http://localhost:80/cgi-bin
ProxyPassReverse /cgi http://localhost:80/cgi-bin
ProxyPass / http://localhost:8888/
ProxyPassReverse / http://localhost:8888/

</VirtualHost>
Далее при запуске в hosted mode надо просто поменять в адрессной строке localhost:8888 на localhost:8889 и всё будет работать.

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

Второй метод я проверять не стал, но вкратце он заключается в использовании org.apache.catalina.servlets.CGIServlet для запуска cgi-скриптов. Подробнее см. по ссылке на источник.

Источник: http://groups.google.ru/group/...

воскресенье, сентября 16, 2007

CPAN баги и LWP

Сейчас стало модно говорить о пришествии Perl6 и о всяких его вкусностях. Это всё конечно интересно, но здесь и сейчас большинству приходится писать на пятёрке.

Вот довелось мне недавно опять использовать LWP. Я его не очень люблю, но учитывая весьма куцый Curl под perl который вобщем в заброшенном состоянии, выбор вобщем не велик... Ну зачитал я доку по LWP::UserAgent где написано следующее:
$ua = LWP::UserAgent->new( %options )

This method constructs a new LWP::UserAgent object and returns it. Key/value pair arguments may be provided to set up the initial state. The following options correspond to attribute methods described below:

   KEY                     DEFAULT
----------- --------------------
agent "libwww-perl/#.##"
from undef
conn_cache undef
cookie_jar undef

default_headers HTTP::Headers->new

max_size undef
max_redirect 7
parse_head 1
protocols_allowed undef
protocols_forbidden undef
requests_redirectable ['GET', 'HEAD']
timeout 180

The following additional options are also accepted: If the env_proxy option is passed in with a TRUE value, then proxy settings are read from environment variables (see env_proxy() method below). If the keep_alive option is passed in, then a LWP::ConnCache is set up (see conn_cache() method below). The keep_alive value is passed on as the total_capacity for the connection cache.


Я специально выделил default_headers. Так вот передавать в конструктор этот параметр бесполезно - он просто никак там не обрабатывается. Убив на поиск этого неочевидного бага несколько часов, я пошёл о нём рапортовать. И нашёл его в баглисте, добавлен он был в декабре аж 2005 года: http://rt.cpan.org/Public/Bug/Display.html?id=16637 . Может автор забросил это дело вообще, подумал я и глянул на resolved bugs . Нет не забросил - всего пять недель назад баги активно правились. Вобщем не понять мне почему не исправить эту ошибку(решение - дело пары строчек), которая прямо скажем много вреда наносит (особенно если "тут работает, а там не работает")...

Такие вот тяжёлые будни, а вы говорите Perl6... Будем верить в лучшее. :)