проблемы с ssl backend

nginx работает как фронтенд для HTTPS сервера(Tomcat), возникла
проблема коммуникации с бэкэндом.
конфиг:

location / {
    proxy_pass https://XXX.XXX.XXX.XXX:443;
}

первый запрос проходит нормально, все остальные
возвращают 502.
пробовал обновить OS(Linux FC10-FC11), openssl(0.9.8g до 0.9.8k), не помогло,
при этом не возникло проблем под FreeBSD на подобном конфиге;
возможно что-то не так в обработчике epoll, хотя на CentOS проблему
воспроизвести также не удалось.

Пожалуйста, помогите локализовать и устранить проблему?
Спасибо.

лог 2 последовательных запросов в режиме debug прилагаю.

2009/06/30 22:34:25 [debug] 6737#0: *4 http cl:-1 max:1048576
2009/06/30 22:34:25 [debug] 6737#0: *4 generic phase: 2
2009/06/30 22:34:25 [debug] 6737#0: *4 post rewrite phase: 3
2009/06/30 22:34:25 [debug] 6737#0: *4 generic phase: 4
2009/06/30 22:34:25 [debug] 6737#0: *4 access phase: 5
2009/06/30 22:34:25 [debug] 6737#0: *4 access phase: 6
2009/06/30 22:34:25 [debug] 6737#0: *4 access phase: 7
2009/06/30 22:34:25 [debug] 6737#0: *4 post access phase: 8
2009/06/30 22:34:25 [debug] 6737#0: *4 http init upstream, client timer: 0

Re: Проблема с редиректом http на https.

Re: Переменные $cookie_name

On Saturday, June 27, 2009 at 7:29:43, Volkov Oleg wrote:

VO> Зачем изобретать велосипед?
VO> url кодируется: %XX
VO> где XX - hex код произвольного символа

разговор был про имена переменных

$cookie_*
$http_*
$arg_*

и т.п.

--

-- 
Best regards,
 Gena

Re: Проблема с редиректом http на https.

On Tuesday, June 30, 2009 at 18:48:12, LinCore wrote:

L> Возникла необходимость сделать ssl бэкэнд с
фонтэндом на основе
L> nginx, но используя нестандартный порт (например 8081).

L> Пример конфигурационого фаила:
L> cat nginx.conf

L>  server { 

L>     listen       some_ip:8081;

L>     server_name some_name_tld;

L>     ssl          on;

L>     rewrite ^ https://$server_name:$server_port$request_uri redirect;

[...]

L> И в такой конфигурации редирект который я использую
не работает,
L> причем если фронтэнд повесить на 80 порт то всё
начинает работать как надо.

если в конфигурации написано listen some_ip:8081; ssl on;
- то это уже "http over ssl". ничего редиректить не надо.

если попробовать обратиться по http-протоколу на https порт,
http://example.com:443/ то nginx вернет сообщение об ошибке:

==============================================

400 Bad Request

The plain HTTP request was sent to HTTPS port

==============================================

поэтому для plain http нужно выделять отдельный порт,
например, так: 80 - plain http, 443 - http over ssl.

--

-- 
Best regards,
 Gena

Re: Переменные $cookie_name

2009/7/1 Gena Makhomed <gmm <at> csdoc.com>:
> On Saturday, June 27, 2009 at 7:29:43, Volkov Oleg wrote:
>
> VO> Зачем изобретать велосипед?
> VO> url кодируется: %XX
> VO> где XX - hex код произвольного символа
>
> разговор был про имена переменных
>
> $cookie_*
> $http_*
> $arg_*
>
> и т.п.
>

Он предлагает значение заголовка app_domain класть в переменную
$http_app%5Fdomain.

Именно про эти имена, ага.

> --
> Best regards,
>  Gena
>
>
>

Re: проблемы с ssl backend

Hello!

On Wed, Jul 01, 2009 at 04:37:25AM +0400, Sergey Petrov wrote:

> nginx работает как фронтенд для HTTPS сервера(Tomcat), возникла
> проблема коммуникации с бэкэндом.
> конфиг:
> 
> location / {
>     proxy_pass https://XXX.XXX.XXX.XXX:443;
> }
> 
> 
> первый запрос проходит нормально, все остальные
возвращают 502.
> пробовал обновить OS(Linux FC10-FC11), openssl(0.9.8g до 0.9.8k), не помогло,
> при этом не возникло проблем под FreeBSD на подобном конфиге;
> возможно что-то не так в обработчике epoll, хотя на CentOS проблему
> воспроизвести также не удалось.

Вероятно поможет downgrade openssl до 0.9.8e. Как workaround 
можно попробовать

    proxy_ssl_session_reuse  off;

Проблема судя по всему кроется где-то в районе
появления в openssl 
поддержки TLS extensions, в частности - RFC4507bis session 
tickets.

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

Maxim Dounin

Проблема с релоадом nginx

Здравствуйте,

Выполняю:

/etc/init.d/nginx reload
Can't locate nginx.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8
/usr/lib/perl5/site_perl/5.8.8/i686-linux
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_per
l/5.8.7/i686-linux /usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_p
erl/5.8.1 /usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.2 /usr/lib/perl5/site_perl .).
BEGIN failed--compilation aborted.
2009/07/01 20:08:56 [alert] 5965#0: perl_parse() failed: 2
2009/07/01 20:08:56 [emerg] 5965#0: the configuration file
/etc/nginx/nginx.conf test failed

Далее сразу:

service nginx reload
Reloading nginx: [  OK  ]

Чем можно обьяснить такое поведение? Система CentOS 5.2, nginx
собирался из RPM 0.7.32.
Кстати, рестарт по умолчанию тоже не работает,
сколько не ставил nginx
на CentOS нигде не работал рестарт без добавления
ожидания между
остановкой/запуском.

Re: Проблема с релоадом nginx

On Wednesday, July 1, 2009 at 20:28:59, Алексей wrote:

А> Система CentOS 5.2, nginx собирался из RPM 0.7.32.

А> Кстати, рестарт по умолчанию тоже не работает,
сколько не ставил nginx
А> на CentOS нигде не работал рестарт без добавления
ожидания между
А> остановкой/запуском.

да, restart корректно не работает потому что там есть
ошибка в инит-скрипте.
хотя вместо restart лучше использовать reload или force-reload aka upgrade.

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

--

-- 
Best regards,
 Gena

Странный вывод tcpdump и странное поведение nginx.

Nginx-0.7.57, Centos 5.3. Сервер стоит за nat на циске.
Захватить процесс установки соединения увы не
повезло, но и так довольно странно.

# tcpdump -nn -A -r /root/out-195.19.34.12 port 60377
reading from file /root/out-195.19.34.12, link-type LINUX_SLL (Linux cooked)
11:43:18.699865 IP 195.19.34.12.60377 > 10.0.0.51.80: . 3130523895:3130524063(168) ack 933405067
win 4200
E...E...w...Q..g
..3...P....7...P..h....GET /site/common/UserPost?re?re
11:43:18.699873 IP 10.0.0.51.80 > 195.19.34.12.60377: . ack 168 win 26
E..({.@.@.D.
..3Q..g.P..7.......P.......
11:43:19.302642 IP 10.0.0.51.80 > 195.19.34.12.60377: F 1:1(0) ack 168 win 26
E..({.@.@.D.
..3Q..g.P..7.......P.......
11:43:19.339373 IP 195.19.34.12.60377 > 10.0.0.51.80: . ack 2 win 4200
E..(E...w...Q..g
..3...P....7...P..h.z........
11:43:23.726963 IP 195.19.34.12.60377 > 10.0.0.51.80: . 168:376(208) ack 2 win 4200
E...E...w...Q..g
..3...P....7...P..hg...ntireAgency=yes&tPattern=&sortColumn=sta
11:43:23.726972 IP 10.0.0.51.80 > 195.19.34.12.60377: R 933405068:933405068(0) win 0
E..(..@.@..n
..3Q..g.P..7.......P...p&..

Почему nginx пытается закрыть соединение? Почему
клиент продолжает слать данные и получает RST?

Re: Проблема с редиректом http на https.