патч для отключения заголовков "Connection: keep-alive" (еще раз)
Добрый день!
как-то уже писал на эту тему. дошли руки, выкатил патч в продакшен.
идея в том, что отправка заголовка "Connection: keep-alive" в
большинстве случаев не нужна.
абонентская база - сотни тысяч пользователей, сотни миллионов запросов
в месяц. думаю, спустя месяц-два можно будет считать, что все
протестировано во всех возможных ситуациях.
желающие - приглашаются к тестированию.
данное поведение "подсмотрено" у IIS, который по любым метрикам
занимает десятки процентов "рынка":
http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html
- поэтому есть уверенность, что все обойдется без побочных эффектов
diff --git a/src/http/ngx_http_header_filter_module.c
b/src/http/ngx_http_header_filter_module.c
index 707a813..759186f 100644
--- a/src/http/ngx_http_header_filter_module.c
+++ b/src/http/ngx_http_header_filter_module.c
@@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_t *r)
len += sizeof("Connection: upgrade" CRLF) - 1;
} else if (r->keepalive) {
+
+if ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) {
len += sizeof("Connection: keep-alive" CRLF) - 1;
+}
/*
* MSIE and Opera ignore the "Keep-Alive: timeout=" header.
@@ -556,8 +559,10 @@ ngx_http_header_filter(ngx_http_request_t *r)
sizeof("Connection: upgrade" CRLF) - 1);
} else if (r->keepalive) {
-b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
+ if ((r->http_version == NGX_HTTP_VERSION_10) ||
(clcf->keepalive_header)) {
+ b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
sizeof("Connection: keep-alive" CRLF) - 1);
+ }
if (clcf->keepalive_header) {
b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF,
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
http browser module — ancient browser
День добрый!
Вопрос такой. Должны ли дериктивы модуля http_browser располагаться в том же
блоке (http, server, location), что и проверка соответствующих переменных? В
документации об этом ни слова.
А то у меня что-то криво работал код if ($ancient_browser) { ... } внутри
location — получалось always true, когда директивы modern_browser и
ancient_browser заданы на уровне server.
--
Ruvim
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245376,245376#msg-245376
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: write $request_body to the log
2013/12/9 Maxim Dounin : > Сейчас - есть ручка во встроенном перле, $r->has_request_body(). это один из тез трех вариантов, что мне не нравятся... ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Прокси HTTPS на nginx/1.5.4 собранный вручную vs nginx/1.5.7 из репозитория
On 09.12.2013, at 18:34, mnsold wrote: >> Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к > glassfish'у: >> openssl s_client -debug -connect localhost:8002 > > Включил >> -Djavax.net.debug=ssl > > На данный момент openssl > # openssl version > OpenSSL 1.0.1e 11 Feb 2013 > # dpkg -l|grep openssl > ii openssl 1.0.1e-2 > > но nginx 1.5.7 использует все равно 0.9.8: Добавьте proxy_ssl_protocols SSLv3; Посмотрите, исчезнет ли проблема. Проблема, возможно, в том, что nginx с openssl 0.9.8 шлет session ticket, который вызывает ошибку в реализации SSL в java. Чтобы убедиться поставьте openssl из 0.9.8 и проверьте s_client c и без -no_ticket. openssl из 1.0.1e у вас тикет не шлет. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: write $request_body to the log
Hello! On Mon, Dec 09, 2013 at 06:04:17PM +0400, Daniel Podolsky wrote: > 2013/12/9 Maxim Dounin : > > Тело запроса читается только в том случае, если оно нужно (e.g, мы > > собрались его передавать на бекенда) > Это терминологическая путаница. Мне это тело нужно, но передавать я > его никуда не собираюсь. > > Нет ли какого полезного ключа "прочесть тело, даже если проксирование > не прописано"? Если нет - нельзя ли его сделать? > > А то сейчас у меня три варианта, и все они плохие. Сейчас - есть ручка во встроенном перле, $r->has_request_body(). http://nginx.org/ru/docs/http/ngx_http_perl_module.html#methods -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Прокси HTTPS на nginx/1.5.4 собранный вручную vs nginx/1.5.7 из репозитория
> Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к glassfish'у: > openssl s_client -debug -connect localhost:8002 Включил > -Djavax.net.debug=ssl На данный момент openssl # openssl version OpenSSL 1.0.1e 11 Feb 2013 # dpkg -l|grep openssl ii openssl 1.0.1e-2 но nginx 1.5.7 использует все равно 0.9.8: # ldd `which nginx` linux-vdso.so.1 => (0x7fffae33d000) libpthread.so.0 => /lib/libpthread.so.0 (0x7fdd24f6b000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x7fdd24d34000) libpcre.so.3 => /lib/libpcre.so.3 (0x7fdd24b03000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x7fdd248ac000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x7fdd2450b000) libz.so.1 => /usr/lib/libz.so.1 (0x7fdd242f3000) libc.so.6 => /lib/libc.so.6 (0x7fdd23f91000) /lib64/ld-linux-x86-64.so.2 (0x7fdd25195000) libdl.so.2 => /lib/libdl.so.2 (0x7fdd23d8d000) nginx 1.5.4: # ldd `which /data/nginx-gost/sbin/nginx` linux-vdso.so.1 => (0x7fff695ff000) libpthread.so.0 => /lib/libpthread.so.0 (0x7ff4330f4000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x7ff432ebd000) libpcre.so.3 => /lib/libpcre.so.3 (0x7ff432c8c000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7ff432a2d000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7ff432649000) libdl.so.2 => /lib/libdl.so.2 (0x7ff432444000) libz.so.1 => /usr/lib/libz.so.1 (0x7ff43222d000) libc.so.6 => /lib/libc.so.6 (0x7ff431ecb000) /lib64/ld-linux-x86-64.so.2 (0x7ff43331e000) # openssl s_client -connect localhost:8002 -tlsextdebug CONNECTED(0003) depth=0 C = US, ST = California, L = Santa Clara, O = Oracle Corporation, OU = GlassFish, CN = myhost.domain.local verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = California, L = Santa Clara, O = Oracle Corporation, OU = GlassFish, CN = myhost.domain.local verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local i:/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local --- Server certificate -BEGIN CERTIFICATE- MIICsDCCAhmgAwIBAgIEUTCRSzANBgkqhkiG9w0BAQUFADCBijELMAkGA1UEBhMC VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRsw GQYDVQQKExJPcmFjbGUgQ29ycG9yYXRpb24xEjAQBgNVBAsTCUdsYXNzRmlzaDEf MB0GA1UEAxMWb2N0b3B1cy5sYW4uaWFjLnNwYi5ydTAeFw0xMzAzMDExMTMwMTla Fw0yMzAyMjcxMTMwMTlaMIGKMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jw b3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMR8wHQYDVQQDExZvY3RvcHVzLmxh bi5pYWMuc3BiLnJ1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHZ0/bGIlY r12glRa0B8ykVXGuXtzbNr6cqOlQ5ELkyAlW1zwju/JSPxw00zy/elOep/VMFlAg K7Sp+xQYqueWgF6u+05K1FTZeQSsgVO3fSkwbBiX4ObUVawuZoTW0tUs8t1RLUm6 widfiIsFrEjrbMWJ5xqxMwBzMdQnyggN3wIDAQABoyEwHzAdBgNVHQ4EFgQUPsyT ixhlk4gfm5ripc8C1E+J8EwwDQYJKoZIhvcNAQEFBQADgYEAAuaaVnxJN4jsxqHT AAwNyJl0493xApcKnWCFjdugNbCMvv0ez2tYJ4xuQsG0G4rL/zPLATJvQbJM36TO JGXR4P3S/QIDFYDpy6cpCBqg/2P0c/vwh/mK5U10sWnrbfLUlh5sBCM1jza3/wtX /Vqm9py36r3NhaX7hF2KKLG1s7A= -END CERTIFICATE- subject=/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local issuer=/C=US/ST=California/L=Santa Clara/O=Oracle Corporation/OU=GlassFish/CN=myhost.domain.local --- No client certificate CA names sent --- SSL handshake has read 1264 bytes and written 478 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: EDH-RSA-DES-CBC3-SHA Session-ID: 52A5C7084B96822C644DA72CADECFADD2C8684AFE17E63158BD8EB90819682B1 Session-ID-ctx: Master-Key: ECB9F34696C2F27C330007773E9272D9FE539517AC74FD3E94F5CF105AA77BF2DFFEFEE93BE22066F68D42CB080F289F Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1386596104 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- Если дедлаю запрос с nginx 1.5.7 (из репозитория), в логах glassfish'а: [#|2013-12-09T18:27:35.338+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|Using SSLEngineImpl.|#] [#|2013-12-09T18:27:35.338+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5), READ: TLSv1 Handshake, length = 89|#] [#|2013-12-09T18:27:35.339+0400|INFO|oracle-glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=36;_ThreadName=Thread-2;|http-thread-pool-8002(5), fatal error: 80: problem unwrapping net record javax.net.ssl
Re: использование ngx http headers module
On Wednesday 04 December 2013 20:42:21 hexiw wrote: > Здравствуйте, уважаемые форумчане :) Недавно мне понадобилось добавить в > заголовки ответа нестандартный заголовок, мне удалось нагуглить модуль > ngx_http_headers_module и, судя по описанию, он меня целиком устраивает. Но > я не могу понять как его использовать и куда писать, нужные мне, строки. > Буду благодарен если кто подскажет как вообще работать с модулями nginx и > конкретно с ngx_http_headers_module. > И чем документация не устроила? http://nginx.org/ru/docs/http/ngx_http_headers_module.html -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: write $request_body to the log
2013/12/9 Maxim Dounin : > Тело запроса читается только в том случае, если оно нужно (e.g, мы > собрались его передавать на бекенда) Это терминологическая путаница. Мне это тело нужно, но передавать я его никуда не собираюсь. Нет ли какого полезного ключа "прочесть тело, даже если проксирование не прописано"? Если нет - нельзя ли его сделать? А то сейчас у меня три варианта, и все они плохие. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Прокси HTTPS на nginx/1.5.4 собранный вручную vs nginx/1.5.7 из репозитория
On 09.12.2013, at 16:55, mnsold wrote: > Подскажите, как локализовать причину. Попробуйте подключиться _штатным_ ( из пакетов ) s_client'ом к glassfish'у: openssl s_client -debug -connect localhost:8002 Посмотрите пройдет ли ssl handshake и если не пройдет, то почему. Посмотрите на glassfish'евский server.log, добавьте, если из лога не будет понятна причина, -Djavax.net.debug=ssl в список параметров для джавы. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: write $request_body to the log
Hello! On Mon, Dec 09, 2013 at 04:30:14PM +0400, Daniel Podolsky wrote: > Добрый день! > > В некотором локейшене хочу принять post и записать его в лог. > Проксировать его мне никуда не надо, просто принять и записать. > > Данных там не много, должны влезать в память. > > Вроде бы, для этой цели должна подойти переменная $request_body. > > Но в документации написано: > === > $request_body: тело запроса > Значение переменной появляется в location'ах, обрабатываемых > директивами proxy_pass и fastcgi_pass. > === > > По моим наблюдениям - и правда, для локейшенов без проксирования в > переменной пусто. > > Я чего-то недопонял, или так оно и есть? Тело запроса читается только в том случае, если оно нужно (e.g, мы собрались его передавать на бекенда). Если не нужно (e.g., при возврате статических файлов или ошибок) - оно просто отбрасывается, и в этом случае в переменной $request_body будет пусто. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Прокси HTTPS на nginx/1.5.4 собранный вручную vs nginx/1.5.7 из репозитория
Есть два сервера nginx к томуже с разными openssl
1. nginx и opensl собрана вручную (opensl нужна для поддержки ГОСТА), вот
эти версии:
nginx/1.5.4+OpenSSL 1.0.1e 11 Feb 2013
2. nginx и opensl установленаая из репозитория дебиана, вот эти версии:
nginx/1.5.7+OpenSSL 0.9.8o 01 Jun 2010(пробовал так же OpenSSL 1.0.1e )
Оба сервера nginx с openssl установлены на одном хосте. В качестве бэкэнда
стоит glassfish 3.1.1.
При проксировании в связке конфигурации nginx и opensl (собранные вручную)
все нормально проксируется.
При проксировании в связке конфигурации nginx и opensl (установленные из
репозитория) glassfish не проксируется, пишет "502 Bad Gateway".
В логе видно:
2013/12/09 16:45:59 [info] 4630#0: *5 peer closed connection in SSL
handshake while SSL handshaking to upstream, client: 192.168.44.151, server:
localhost, request: "GET /ised HTTP/1.1", upstream:
"https://127.0.0.1:8002/ised";, host: "myhost.lan.iac.spb.ru:8183"
Замечу, что связка в конфигурации nginx и opensl (установленные из
репозитория) прекрасно проксирует https на apache.
Подскажите, как локализовать причину.
Спасибо!
Конфиг понятное дело одинаковый, разниза только в портах на которых он
доступен, сам конфиг:
server {
listen *:8183 ssl;
server_name myhost;
ssl_certificate /data/cert-ssl/server.crt;
ssl_certificate_key /data/cert-ssl/server.key;
location / {
proxy_pass https://localhost:8002;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto$scheme;
}
error_log /var/log/nginx/error.log debug;
access_log /var/log/nginx/access.log main;
}
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245360,245360#msg-245360
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
write $request_body to the log
Добрый день! В некотором локейшене хочу принять post и записать его в лог. Проксировать его мне никуда не надо, просто принять и записать. Данных там не много, должны влезать в память. Вроде бы, для этой цели должна подойти переменная $request_body. Но в документации написано: === $request_body: тело запроса Значение переменной появляется в location'ах, обрабатываемых директивами proxy_pass и fastcgi_pass. === По моим наблюдениям - и правда, для локейшенов без проксирования в переменной пусто. Я чего-то недопонял, или так оно и есть? Спасибо. С уважением, Даниил Подольский. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: listen на всех ип кроме 127/8
А с linux/openvz совсем вариантов нет? И даже никакого workaround-да, чтобы попроще, чем переписывать все конфиги? 04.12.2013 11:06, Igor Sysoev пишет: [...] >>> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, >>> наверное, IPv6:::1) ? >>> >>> Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть >>> именно на 80ом порту, а внешний(ие) ип (на которые должен биндится >>> нгинх) часто меняются (и их количество вообще может быть не известно, >>> отвечать надо на всех). Хочется делать релоад нгинх без переписывания >>> кучи конфигов (виртуалхостов - много, очень много). >> >> А что за система и ядро? Многие современные, > > [ не Линуксы ] > >> IIUC, позволяют одному слушать на >> *:80 и остальным откусывать у него specific:80 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настроить HTTP и HTTPS на одном сервере
Помогла директива proxy_redirect http://$http_host $scheme://$http_host; Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245351#msg-245351 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настроить HTTP и HTTPS на одном сервере
Точно знаю, что поможет директива proxy_redirect http://$http_host https://$http_host; Но не знаю, как ее можно применить только если $scheme=https. В "if ( $scheme = "https" ) ... " не работает, т.к. nginx пишет "proxy_redirect" directive is not allowed here" Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245349#msg-245349 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настроить HTTP и HTTPS на одном сервере
Dmitriy Lyalyuev Wrote: --- > Добрый день. > > proxy_set_header X-Forwarded-Proto $scheme; Пробовал данную директиву и форсировал ее вместо "$scheme" явно прописывал "https", но не срабатывает. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245346,245348#msg-245348 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Настроить HTTP и HTTPS на одном сервере
Добрый день.
proxy_set_header X-Forwarded-Proto $scheme;
09.12.2013 11:24, mnsold пишет:
Основная проблема: по HTTPS перенаправляет на HTTP протокол, вместо HTTPS.
По HTTP все отрабатывает нормально.
Локальный сетевой трафик хочется по HTTP гонять (и проблемы видимо отсюда и
растут), чтобы не нагружать сервер, да и весь локальный трафик между
серверами считаю доверенным.
В качестве бэкэнда стоит апач.
Само перенаправление (без слэша в конце), как оно проиходит.
Тут все нормально:
http://myhost/context -> http://myhost/context/
А вот тут перенаправляет на HTTP, вместо HTTPS
https://myhost/context -> http://myhost/context/
Подскажите, как нужно поправить конфиг, чтобы перенаправлял на HTTPS, при
условии что хочется внутренний трафик гонять по HTTP?
Конфиги:
server {
listen *:80;
listen *:443 ssl;
server_name myhost;
ssl_certificate /.../server.crt;
ssl_certificate_key /.../server.key;
ssl_protocols SSLv2 SSLv3;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_verify_client off;
include conf.d/test-apache.cfg;
error_log /var/log/nginx/error.log warn;
access_log /var/log/nginx/access.log main;
}
Файл test-apache.cfg
location ^~ / {
proxy_pass http://localhost:80;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Замечено, что если в proxy_pass отправлять по https то все работает
нормально, например:
в файле test-apache.cfg заменить
proxy_pass http://localhost:80;
на
if ( $scheme = "http" ) {
proxy_pass http://localhost:80;
}
if ( $scheme = "https" ) {
proxy_pass https://localhost:443;
}
На стороне апача на данный момент все предельно просто
Alias /context "/var/www/context"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245346,245346#msg-245346
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Dmitriy Lyalyuev
http://lyalyuev.info
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Настроить HTTP и HTTPS на одном сервере
Основная проблема: по HTTPS перенаправляет на HTTP протокол, вместо HTTPS.
По HTTP все отрабатывает нормально.
Локальный сетевой трафик хочется по HTTP гонять (и проблемы видимо отсюда и
растут), чтобы не нагружать сервер, да и весь локальный трафик между
серверами считаю доверенным.
В качестве бэкэнда стоит апач.
Само перенаправление (без слэша в конце), как оно проиходит.
Тут все нормально:
http://myhost/context -> http://myhost/context/
А вот тут перенаправляет на HTTP, вместо HTTPS
https://myhost/context -> http://myhost/context/
Подскажите, как нужно поправить конфиг, чтобы перенаправлял на HTTPS, при
условии что хочется внутренний трафик гонять по HTTP?
Конфиги:
server {
listen *:80;
listen *:443 ssl;
server_name myhost;
ssl_certificate /.../server.crt;
ssl_certificate_key /.../server.key;
ssl_protocols SSLv2 SSLv3;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_verify_client off;
include conf.d/test-apache.cfg;
error_log /var/log/nginx/error.log warn;
access_log /var/log/nginx/access.log main;
}
Файл test-apache.cfg
location ^~ / {
proxy_pass http://localhost:80;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Замечено, что если в proxy_pass отправлять по https то все работает
нормально, например:
в файле test-apache.cfg заменить
proxy_pass http://localhost:80;
на
if ( $scheme = "http" ) {
proxy_pass http://localhost:80;
}
if ( $scheme = "https" ) {
proxy_pass https://localhost:443;
}
На стороне апача на данный момент все предельно просто
Alias /context "/var/www/context"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245346,245346#msg-245346
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
