Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
Валентин Бартенев Wrote: --- > 2. Похоже у вас nginx собран со сторонними модулями и некоторые даже > активно > используются. В этом случае первое, что следует сделать - это > убедиться, что > проблема вообще воспроизводится без сторонних модулей. > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Похоже что они, а именно headers_more + subs_filter. Именно вместе - если закомментировать любой, то вроде не воспроизводится Posted at Nginx Forum: https://forum.nginx.org/read.php?21,275235,275272#msg-275272 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
On Saturday 01 July 2017 05:11:34 Дмитрий Герасимов wrote: > Валентин Бартенев Wrote: > --- > > > На странице https://viparenda.ru/test.html - действительно, в хроме > > ошибку > > наблюдаю. > > > > Для nginx нужен такой лог: http://nginx.org/ru/docs/debugging_log.html > > > > -- > > Валентин Бартенев > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > Такс - файлы сюда добавлять нельзя, поэтому ссылка на копию этого лога после > того, как воспроизвёл ошибку. https://viparenda.ru/test-debug.txt. SSI > который вызывает ошибку - /ajax/catalog/SEO/arenda_ofisa.php > 1. Лог, к сожалению, неполный. Похоже он у вас был включен не на глобальном уровне в конфигурации, как требуется для логгирования всего. Поэтому часть ценной информации в нем не отражено. 2. Похоже у вас nginx собран со сторонними модулями и некоторые даже активно используются. В этом случае первое, что следует сделать - это убедиться, что проблема вообще воспроизводится без сторонних модулей. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
Валентин Бартенев Wrote: --- > На странице https://viparenda.ru/test.html - действительно, в хроме > ошибку > наблюдаю. > > Для nginx нужен такой лог: http://nginx.org/ru/docs/debugging_log.html > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Такс - файлы сюда добавлять нельзя, поэтому ссылка на копию этого лога после того, как воспроизвёл ошибку. https://viparenda.ru/test-debug.txt. SSI который вызывает ошибку - /ajax/catalog/SEO/arenda_ofisa.php Posted at Nginx Forum: https://forum.nginx.org/read.php?21,275235,275247#msg-275247 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
On Friday 30 June 2017 11:12:40 Дмитрий Герасимов wrote: > Валентин Бартенев Wrote: > --- > > Нужен дебаг лог с nginx и из Хрома (вкладка chrome://net-internals) > > при появлении такой ошибки. > > > > Без этого искать проблему можно вечность, протокол SPDY, он же HTTP/2, > > > > невероятно сложен для дебага, а тут ещё накладываются факторы в виде > > кэша и асинхронного SSI. > > > > -- > > Валентин Бартенев > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Про хром можно проверить здесь https://viparenda.ru/test.html - статичная > копия той страницы, соотв. "убивающий" ssi wait заменён на no. Про nginx не > очень понятно, что именно нужно? > На странице https://viparenda.ru/test.html - действительно, в хроме ошибку наблюдаю. Для nginx нужен такой лог: http://nginx.org/ru/docs/debugging_log.html -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
Валентин Бартенев Wrote: --- > Нужен дебаг лог с nginx и из Хрома (вкладка chrome://net-internals) > при появлении такой ошибки. > > Без этого искать проблему можно вечность, протокол SPDY, он же HTTP/2, > > невероятно сложен для дебага, а тут ещё накладываются факторы в виде > кэша и асинхронного SSI. > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Про хром можно проверить здесь https://viparenda.ru/test.html - статичная копия той страницы, соотв. "убивающий" ssi wait заменён на no. Про nginx не очень понятно, что именно нужно? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,275235,275237#msg-275237 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ERR SPDY PROTOCOL ERROR при SSI в хроме
On Friday 30 June 2017 07:51:39 Дмитрий Герасимов wrote: > Всем доброго дня/вечера. Есть страница https://viparenda.ru/arenda_ofisa/ . > Не так давно на ней в хроме периодически начала появляться данная ошибка > (только на ней и только в хромоподобных браузерах. В FF и Edge сколько не > пытался, так и не получилось её добиться). В логах при этом было пусто, > только в access_log $body_bytes_sent был равен 0. Единственное что сильно > отличает её от подобных страниц это "плашка" внизу страницы с 8 рандомными > объектами, которая подгружалась при помощи ssi + fastcgi_cache, т.к. все > страницы с результатами поиска также кешируются. Проблема решилась > выставлением wait="yes", так что вопросов нет. Хотелось просто донести > информацию и таки разобраться. Ведь иногда она таки отрабатывалась > нормально, также у основной страницы и ssi разное время кеширования (1 час и > 1 день соответственно). Nginx 1.13.2, но появилось гораздо раньше. На > странице суммарно 3 ssi запроса, на остальных по 2 > [..] Нужен дебаг лог с nginx и из Хрома (вкладка chrome://net-internals) при появлении такой ошибки. Без этого искать проблему можно вечность, протокол SPDY, он же HTTP/2, невероятно сложен для дебага, а тут ещё накладываются факторы в виде кэша и асинхронного SSI. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
ERR SPDY PROTOCOL ERROR при SSI в хроме
Всем доброго дня/вечера. Есть страница https://viparenda.ru/arenda_ofisa/ . Не так давно на ней в хроме периодически начала появляться данная ошибка (только на ней и только в хромоподобных браузерах. В FF и Edge сколько не пытался, так и не получилось её добиться). В логах при этом было пусто, только в access_log $body_bytes_sent был равен 0. Единственное что сильно отличает её от подобных страниц это "плашка" внизу страницы с 8 рандомными объектами, которая подгружалась при помощи ssi + fastcgi_cache, т.к. все страницы с результатами поиска также кешируются. Проблема решилась выставлением wait="yes", так что вопросов нет. Хотелось просто донести информацию и таки разобраться. Ведь иногда она таки отрабатывалась нормально, также у основной страницы и ssi разное время кеширования (1 час и 1 день соответственно). Nginx 1.13.2, но появилось гораздо раньше. На странице суммарно 3 ssi запроса, на остальных по 2 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,275233,275233#msg-275233 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: spdy большой ttfb
если используете limit_req, то убедитесь, что его действие не распространяется на раздачу статики. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,261748,262696#msg-262696 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: spdy большой ttfb
On Wednesday 23 September 2015 12:24:14 Maxim Valeev wrote: > Добрый день! > > Не могу понять чем обусловлен такой большой Waiting (TTFB), если обращаться > напрямую, то отдается все махом. > > Скрин с загрузкой > https://drive.google.com/open?id=0B0qFuYdYWHE1YzkwYm5mWlEybFk > > > nginx version: nginx/1.8.0 > built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) > built with OpenSSL 1.0.1f 6 Jan 2014 > TLS SNI support enabled > configure arguments: > --prefix=/usr/share/nginx > --sbin-path=/usr/sbin/nginx > --conf-path=/etc/nginx/nginx.conf > --error-log-path=/var/log/nginx/error.log > --http-log-path=/var/log/nginx/access.log > --pid-path=/var/run/nginx.pid > --lock-path=/var/run/nginx.lock > --http-client-body-temp-path=/var/cache/nginx/client_temp > --http-proxy-temp-path=/var/cache/nginx/proxy_temp > --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp > --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp > --http-scgi-temp-path=/var/cache/nginx/scgi_temp > --user=nginx > --group=nginx > --with-debug > --with-pcre-jit > --with-http_ssl_module > --with-http_realip_module > --with-http_addition_module > --with-http_sub_module > --with-http_dav_module > --with-http_flv_module > --with-http_mp4_module > --with-http_gunzip_module > --with-http_gzip_static_module > --with-http_random_index_module > --with-http_secure_link_module > --with-http_stub_status_module > --with-http_auth_request_module > --with-http_spdy_module > --with-http_geoip_module > --with-http_image_filter_module > --with-http_xslt_module > --with-file-aio > --with-mail > --with-mail_ssl_module > --add-module=/build/nginx-modules/ngx_devel_kit > --add-module=/build/nginx-modules/lua-nginx-module > --add-module=/build/nginx-modules/headers-more-nginx-module > --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -D_FORTIFY_SOURCE=2' > --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' Имеет смысл попробовать без сторонних модулей и снять дебаг-лог. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
spdy большой ttfb
Добрый день! Не могу понять чем обусловлен такой большой Waiting (TTFB), если обращаться напрямую, то отдается все махом. Скрин с загрузкой https://drive.google.com/open?id=0B0qFuYdYWHE1YzkwYm5mWlEybFk nginx version: nginx/1.8.0 built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) built with OpenSSL 1.0.1f 6 Jan 2014 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-debug --with-pcre-jit --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_spdy_module --with-http_geoip_module --with-http_image_filter_module --with-http_xslt_module --with-file-aio --with-mail --with-mail_ssl_module --add-module=/build/nginx-modules/ngx_devel_kit --add-module=/build/nginx-modules/lua-nginx-module --add-module=/build/nginx-modules/headers-more-nginx-module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx-1.9.2 + ssl + spdy segfault
Segfault in nginx-1.9.2 with ssl and spdy module
# nginx -V
nginx version: nginx/1.9.2
built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --user=nginx --group=nginx --prefix=/usr/local/nginx
--sbin-path=/usr/local/nginx/sbin/nginx
--conf-path=/usr/local/nginx/conf/nginx.conf --with-http_ssl_module
--with-http_gzip_static_module --with-http_stub_status_module
--with-http_realip_module --with-debug --with-ipv6 --with-http_spdy_module
--add-module=/home/buildbot/rpm//BUILD/lua-nginx-module-0.9.16
--add-module=/home/buildbot/rpm//BUILD/ngx_devel_kit-0.2.14
# gdb nginx nginx.core
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/nginx/sbin/nginx...done.
[New Thread 24331]
...
#0 ngx_http_spdy_close_stream_handler (ev=0x754eb58) at
src/http/ngx_http_spdy.c:3353
3353src/http/ngx_http_spdy.c: No such file or directory.
in src/http/ngx_http_spdy.c
Missing separate debuginfos, use: debuginfo-install
nginx-rb-1.9.52-1.x86_64
(gdb) directory nginx-1.9.2
Source directories searched: nginx-1.9.2:$cdir:$cwd
(gdb) bt
#0 ngx_http_spdy_close_stream_handler (ev=0x754eb58) at
src/http/ngx_http_spdy.c:3353
#1 0x00482562 in ngx_http_spdy_write_handler (wev=value optimized
out) at src/http/ngx_http_spdy.c:649
#2 0x00435f26 in ngx_event_process_posted (cycle=0xcc6a20,
posted=0x76fcd0) at src/event/ngx_event_posted.c:33
#3 0x0043ce85 in ngx_worker_process_cycle (cycle=0xcc6a20,
data=value optimized out) at src/os/unix/ngx_process_cycle.c:769
#4 0x0043b234 in ngx_spawn_process (cycle=0xcc6a20, proc=0x43cdb0
ngx_worker_process_cycle, data=0x10, name=0x4f98b3 worker process,
respawn=-4) at src/os/unix/ngx_process.c:198
#5 0x0043c1cc in ngx_start_worker_processes (cycle=0xcc6a20, n=23,
type=-4) at src/os/unix/ngx_process_cycle.c:358
#6 0x0043dbd8 in ngx_master_process_cycle (cycle=0xcc6a20) at
src/os/unix/ngx_process_cycle.c:243
#7 0x0041b856 in main (argc=value optimized out, argv=value
optimized out) at src/core/nginx.c:415
(gdb) list
3348ngx_http_request_t *r;
3349
3350fc = ev-data;
3351r = fc-data;
3352
3353ngx_log_debug0(NGX_LOG_DEBUG_HTTP, r-connection-log, 0,
3354 spdy close stream handler);
3355
3356ngx_http_spdy_close_stream(r-spdy_stream, 0);
3357}
(gdb) p r
$1 = (ngx_http_request_t *) 0x0
(gdb) p fc
$2 = (ngx_connection_t *) 0x754ea20
(gdb) p *fc
$3 = {data = 0x0, read = 0x754eaf8, write = 0x754eb58, fd = 1041, recv =
0x4424e0 ngx_ssl_recv, send = 0x441e90 ngx_ssl_write, recv_chain =
0x442990 ngx_ssl_recv_chain, send_chain = 0x484830
ngx_http_spdy_send_chain, listening = 0xcc6f00, sent = 16770,
log = 0x754ebb8, pool = 0x1edb9a0, sockaddr = 0x1edb9f0, socklen = 16,
addr_text = {len = 11, data = 0x1edba50 83.149.9.264}, proxy_protocol_addr
= {len = 0, data = 0x0}, ssl = 0x53307b8, local_sockaddr = 0xe773e0,
local_socklen = 16, buffer = 0x0, queue = {
prev = 0x0, next = 0x0}, number = 68976568, requests = 7, buffered = 2,
log_error = 2, unexpected_eof = 0, timedout = 0, error = 1, destroyed = 1,
idle = 0, reusable = 0, close = 0, sendfile = 1, sndlowat = 1, tcp_nodelay =
2, tcp_nopush = 0, need_last_buf = 1}
(gdb) p ev
$4 = (ngx_event_t *) 0x754eb58
(gdb) p *ev
$5 = {data = 0x754ea20, write = 1, accept = 0, instance = 0, active = 0,
disabled = 0, ready = 1, oneshot = 0, complete = 0, eof = 0, error = 0,
timedout = 0, timer_set = 0, delayed = 0, deferred_accept = 0, pending_eof =
0, posted = 0, closed = 0, channel = 0,
resolver = 0, cancelable = 0, available = 0, handler = 0x47ed90
ngx_http_spdy_close_stream_handler, index = 0, log = 0x754ebb8, timer =
{key = 0, left = 0x0, right = 0x0, parent = 0x0, color = 0 '\000', data = 0
'\000'}, queue = {prev = 0x0, next = 0x0}}
(gdb) f 1
#1 0x00482562 in ngx_http_spdy_write_handler (wev=value optimized
out) at src/http/ngx_http_spdy.c:649
649 wev-handler(wev);
(gdb) list
644
645 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c-log, 0,
646run spdy stream %ui, stream-id);
647
648 wev = stream-request-connection-write;
649 wev-handler(wev);
650 }
651
652 sc-blocked = 0;
653
(gdb) p wev
$6 = value optimized out
(gdb) p stream
$7 = (ngx_http_spdy_stream_t *) 0x66a7150
(gdb) p *stream
$8 = {id = 13, request = 0x66a64c0, connection = 0x39861e0, index = 0x0,
header_buffers = 0, queued = 0
Re: nginx-1.9.2 + ssl + spdy segfault
On Wednesday 01 July 2015 07:28:41 kirimedia wrote: Segfault in nginx-1.9.2 with ssl and spdy module # nginx -V nginx version: nginx/1.9.2 built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) built with OpenSSL 1.0.1e-fips 11 Feb 2013 TLS SNI support enabled configure arguments: --user=nginx --group=nginx --prefix=/usr/local/nginx --sbin-path=/usr/local/nginx/sbin/nginx --conf-path=/usr/local/nginx/conf/nginx.conf --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_realip_module --with-debug --with-ipv6 --with-http_spdy_module --add-module=/home/buildbot/rpm//BUILD/lua-nginx-module-0.9.16 --add-module=/home/buildbot/rpm//BUILD/ngx_devel_kit-0.2.14 [..] Попробуйте без сторонних модулей. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SPDY errors
Здравствуйте. Поймали следующую строчку в логе: inflate() failed: -5 while processing SPDY Это происходит, если сделать гигантскую cookie и спровоцировать внутренний код ошибки 494. Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4. При этом, в http такого поведения не наблюдается. Собственно, в конфиге я делаю вот так: error_page 494 @fallback400; А дальше обрабатываю именованный location. -- Best regards, Anton Kiryushkin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY errors
On Saturday 14 February 2015 20:49:06 Anton Kiryushkin wrote: Здравствуйте. Поймали следующую строчку в логе: inflate() failed: -5 while processing SPDY Это происходит, если сделать гигантскую cookie и спровоцировать внутренний код ошибки 494. Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4. [..] Это было исправлено 3 месяца назад в 1.7.8: http://hg.nginx.org/nginx/rev/abb466a57a22 Стоит обновить nginx до актуальной версии (1.7.10 на данный момент). -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY errors
Спасибо. 14 февраля 2015 г., 22:44 пользователь Валентин Бартенев vb...@nginx.com написал: On Saturday 14 February 2015 20:49:06 Anton Kiryushkin wrote: Здравствуйте. Поймали следующую строчку в логе: inflate() failed: -5 while processing SPDY Это происходит, если сделать гигантскую cookie и спровоцировать внутренний код ошибки 494. Кто-нибудь сталкивался, может быть с такой проблемой? Версия nginx 1.7.4. [..] Это было исправлено 3 месяца назад в 1.7.8: http://hg.nginx.org/nginx/rev/abb466a57a22 Стоит обновить nginx до актуальной версии (1.7.10 на данный момент). -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY
да, очень интересная тема, но спецификации то еще нет http://www.chromium.org/spdy/spdy-protocol http://www.chromium.org/spdy/spdy-protocol на основе чего имплементировать? On Feb 10, 2015, at 10:07 AM, Aleksandr Sytar sytar.a...@gmail.com wrote: В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки HTTP/2 1 - http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY
12 февраля 2015 г., 14:21 пользователь Anatoly Mikhaylov anat...@sonru.com написал: да, очень интересная тема, но спецификации то еще нет http://www.chromium.org/spdy/spdy-protocol на основе чего имплементировать? А это тогда что? - https://tools.ietf.org/html/draft-ietf-httpbis-http2-16 On Feb 10, 2015, at 10:07 AM, Aleksandr Sytar sytar.a...@gmail.com wrote: В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки HTTP/2 1 - http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SPDY
В свете [1] хотелось бы узнать каковы шансы на появление в nginx поддержки HTTP/2 1 - http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx/1.4.6 spdy
On Thursday 22 January 2015 12:02:04 denis wrote: 22.01.2015 10:57, Валентин Бартенев пишет: У вас слишком древняя версия nginx, в которой реализована версия протокола spdy/2, поддержку которой уже исключили из современных браузеров. Вам стоит обновить nginx до 1.7.9. а можно список, какая версия какой протокол умеет? Лучше сразу на сайте Об этом в документации по spdy модулю написано: http://nginx.org/ru/docs/http/ngx_http_spdy_module.html -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
On 20 Jan 2015, at 14:28, Gena Makhomed g...@csdoc.com wrote: On 19.01.2015 14:42, Валентин Бартенев wrote: Вопрос мой ведь в другом, можно ли обойтись иными способами? теоретически - да, если научить nginx смотреть на имя сервера в SNI и на основании этого имени включать или выключать SPDY nginx научить то можно, а клиентов кто при этом научит не ходить на этот сервер по spdy? С точки зрения протокола spdy, его анонс на каком-либо соединении эквивалентен анонсу на всех виртуальных серверах с тем же портом, чьи домены резолвятся в тот же ip, имеют тот же порт и для которых валиден сертификат. Это позволяет запрашивать эти хосты в том же, уже открытом spdy-соединении, тем самым экономя хэндшейки - основной смысл spdy. Всё несколько сложнее, чем кажется. Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. Сейчас - поддержка SNI появилась уже практически во всех серверах и клиентах. Кроме того изменились ситуация с поисковыми машинами и появилась возможность получить бесплатный SSL сертификат: http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html https://letsencrypt.org/ https://www.cloudflare.com/ssl Поэтому в ближайшее время можно ожидать массовое использование SNI для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. Соответственно - можно будет управлять включением/выключением поддержки протокола SPDY для каждого из этих сайтов в отдельности. То есть, теоретически - это сделать возможно. Теоретичкески - невозможно. Есть два сервера на одном listen сокете. Один со SPDY, второй - нет. Пользователь запросил первый сервер. Браузер установил SPDY-соединение к первому. Потом пользователь запросил второй сервер. Браузер пошлёт этот запрос по этому же самому SPDY-соединению. Как его обработать не в рамках SPDY-протокола? Закрыть stream? Вполне возможно, что браузер после этого вообще перестанет работать с данным IP-адресом по SPDY. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
On 19.01.2015 14:42, Валентин Бартенев wrote: Вопрос мой ведь в другом, можно ли обойтись иными способами? теоретически - да, если научить nginx смотреть на имя сервера в SNI и на основании этого имени включать или выключать SPDY nginx научить то можно, а клиентов кто при этом научит не ходить на этот сервер по spdy? С точки зрения протокола spdy, его анонс на каком-либо соединении эквивалентен анонсу на всех виртуальных серверах с тем же портом, чьи домены резолвятся в тот же ip, имеют тот же порт и для которых валиден сертификат. Это позволяет запрашивать эти хосты в том же, уже открытом spdy-соединении, тем самым экономя хэндшейки - основной смысл spdy. Всё несколько сложнее, чем кажется. Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. Сейчас - поддержка SNI появилась уже практически во всех серверах и клиентах. Кроме того изменились ситуация с поисковыми машинами и появилась возможность получить бесплатный SSL сертификат: http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html https://letsencrypt.org/ https://www.cloudflare.com/ssl Поэтому в ближайшее время можно ожидать массовое использование SNI для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. Соответственно - можно будет управлять включением/выключением поддержки протокола SPDY для каждого из этих сайтов в отдельности. То есть, теоретически - это сделать возможно. Другой вопрос - что в этом нет какой-либо большой практической ценности, - совершенно не понятно зачем может кому-либо понадобиться Запретить использовать SPDY. Тем более, что существует простой обходной вариант, - купить/взять в аренду два IP, для spdy on и spdy off соответственно. И даже если бы были какие-то веские причины, чтобы сделать spdy параметром сервера, а не параметром listen сокета - это сделать уже не получится, потому что тогда придется сломать обратную совместимость. То есть, овчинка выделки наверное не стоит. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
On Monday 19 January 2015 13:27:56 Gena Makhomed wrote: On 18.01.2015 18:50, Anton Kiryushkin wrote: Вопрос мой ведь в другом, можно ли обойтись иными способами? теоретически - да, если научить nginx смотреть на имя сервера в SNI и на основании этого имени включать или выключать SPDY nginx научить то можно, а клиентов кто при этом научит не ходить на этот сервер по spdy? С точки зрения протокола spdy, его анонс на каком-либо соединении эквивалентен анонсу на всех виртуальных серверах с тем же портом, чьи домены резолвятся в тот же ip, имеют тот же порт и для которых валиден сертификат. Это позволяет запрашивать эти хосты в том же, уже открытом spdy-соединении, тем самым экономя хэндшейки - основной смысл spdy. Всё несколько сложнее, чем кажется. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
On 18.01.2015 18:50, Anton Kiryushkin wrote: Вопрос мой ведь в другом, можно ли обойтись иными способами? теоретически - да, если научить nginx смотреть на имя сервера в SNI и на основании этого имени включать или выключать SPDY практически - нет, потому что такая feature обычно мало кому интересна и нужна, раз такой патч так и не был предоставлен -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
Да, прекрасно. Вот только я не могу слушать отдельный сокет.
18 января 2015 г., 15:49 пользователь Vadim A. Misbakh-Soloviov
m...@mva.name написал:
В письме от Вс, 18 января 2015 14:44:33 пользователь Gena Makhomed написал:
spdy в nginx - это параметр сокета, а не виртуального сервера:
http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
... и отсюда следует что Вы, Anton Kiryushkin), впринципе, можете иметь
spdy
выключенным для конкретного server{} и включенным для остальных...
Только данный server{} должен слушать отдельный от остальных сокет :)
// раз уж начали прямыми подсказками сыпать, то можно и продолжить... :D
--
Best regards,
mva
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Best regards,
Anton Kiryushkin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
К.О. Докупите второй IP ? 2015-01-18 18:56 GMT+03:00 Anton Kiryushkin sw...@fotofor.biz: У меня есть сервер, у которого один адрес. Nginx случает этот адрес на порту 443. И обрабатывает два адреса, для который используется один сертификат. Как, простите, тут можно использовать разные сокеты? Я чего-то не понимаю может быть? -- Regards, Oleg ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
В письме от Вс, 18 января 2015 14:44:33 пользователь Gena Makhomed написал:
spdy в nginx - это параметр сокета, а не виртуального сервера:
http://nginx.org/en/docs/http/ngx_http_core_module.html#listen
... и отсюда следует что Вы, Anton Kiryushkin), впринципе, можете иметь spdy
выключенным для конкретного server{} и включенным для остальных...
Только данный server{} должен слушать отдельный от остальных сокет :)
// раз уж начали прямыми подсказками сыпать, то можно и продолжить... :D
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
Здравствуйте.
Да, все равно так. Я хочу принудительно выключить spdy для конкретного
сервера. Так как, по удивительным причинам, не указывание spdy в конфиге не
отменяет факта, что chrome берет и поднимает spdy соединение. Ну
фантастика. Но по конфигу работать не должно. Но работает.
18 января 2015 г., 8:42 пользователь Vadim A. Misbakh-Soloviov m...@mva.name
написал:
В письме от Вс, 18 января 2015 08:33:04 пользователь Михаил Монашёв
написал:
Если я правильно всё пониманию, то spdy надо специально включать в
конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение
состоит в не включении.
Так ведь, на сколько я понял, товарищ хочет чтобы работало для всех
server{}
кроме одного. И жалуется, что недобавления spdy в listen в этом server{} не
достаточно для того, чтобы SPDY в нём не работал.
// надеюсь, телепатический шлем отработал без ошибок
--
Best regards,
mva
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Best regards,
Anton Kiryushkin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
Спасибо за предложение. Проблема не в том, что у меня нет второго адреса. Вопрос мой ведь в другом, можно ли обойтись иными способами? 18 января 2015 г., 19:17 пользователь Oleg Motienko motie...@gmail.com написал: К.О. Докупите второй IP ? 2015-01-18 18:56 GMT+03:00 Anton Kiryushkin sw...@fotofor.biz: У меня есть сервер, у которого один адрес. Nginx случает этот адрес на порту 443. И обрабатывает два адреса, для который используется один сертификат. Как, простите, тут можно использовать разные сокеты? Я чего-то не понимаю может быть? -- Regards, Oleg ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Best regards, Anton Kiryushkin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
В письме от Вс, 18 января 2015 20:50:30 пользователь Anton Kiryushkin написал: Спасибо за предложение. Проблема не в том, что у меня нет второго адреса. Вопрос мой ведь в другом, можно ли обойтись иными способами? Можно: слушать на другом порту. Или вообще unix-сокет :) // а ещё, не помню, как у NginX с SCTP. -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Запретить использовать SPDY
Здравствуйте. Это, конечно, немного странный вопрос, но можно ли принудительно запретить на каком-то домене использовать spdy? То есть, принудительно его выключить? К сожалению, убирание spdy из listen не спасает. -- Best regards, Anton Kiryushkin ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
Здравствуйте, Anton. Это, конечно, немного странный вопрос, но можно ли принудительно запретить на каком-то домене использовать spdy? То есть, принудительно его выключить? К сожалению, убирание spdy из listen не спасает. Если я правильно всё пониманию, то spdy надо специально включать в конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение состоит в не включении. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
В письме от Вс, 18 января 2015 08:33:04 пользователь Михаил Монашёв написал:
Если я правильно всё пониманию, то spdy надо специально включать в
конфиге nginx-а, чтобы по нему начали ходить. Так что его выключение
состоит в не включении.
Так ведь, на сколько я понял, товарищ хочет чтобы работало для всех server{}
кроме одного. И жалуется, что недобавления spdy в listen в этом server{} не
достаточно для того, чтобы SPDY в нём не работал.
// надеюсь, телепатический шлем отработал без ошибок
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On Jul 7, 2014, at 1:00 PM, Maxim Konovalov ma...@nginx.com wrote: On 6/17/14 5:57 PM, Maxim Konovalov wrote: On 6/17/14 5:54 PM, Anatoly Mikhailov wrote: On 06 Jun 2014, at 16:13, Anatoly Mikhailov anat...@sonru.com wrote: On 06 Jun 2014, at 14:27, Maxim Konovalov ma...@nginx.com wrote: [...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. Отличная новость в пятницу, спасибо! Nginx 1.7.2 содержит именно этот багфикс? Не содержит. JFYI, 1.7.3, выпуск которого назначен на завтра, будет с фиксом: http://mailman.nginx.org/pipermail/nginx-devel/2014-July/005540.html http://trac.nginx.org/nginx/ticket/428 Супер, спасибо! Также здесь решен вопрос с weak etags, золотой релиз! :) -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 6/17/14 5:57 PM, Maxim Konovalov wrote: On 6/17/14 5:54 PM, Anatoly Mikhailov wrote: On 06 Jun 2014, at 16:13, Anatoly Mikhailov anat...@sonru.com wrote: On 06 Jun 2014, at 14:27, Maxim Konovalov ma...@nginx.com wrote: [...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. Отличная новость в пятницу, спасибо! Nginx 1.7.2 содержит именно этот багфикс? Не содержит. JFYI, 1.7.3, выпуск которого назначен на завтра, будет с фиксом: http://mailman.nginx.org/pipermail/nginx-devel/2014-July/005540.html http://trac.nginx.org/nginx/ticket/428 -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 06 Jun 2014, at 16:13, Anatoly Mikhailov anat...@sonru.com wrote: On 06 Jun 2014, at 14:27, Maxim Konovalov ma...@nginx.com wrote: [...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. Отличная новость в пятницу, спасибо! Nginx 1.7.2 содержит именно этот багфикс? -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 6/17/14 5:54 PM, Anatoly Mikhailov wrote: On 06 Jun 2014, at 16:13, Anatoly Mikhailov anat...@sonru.com wrote: On 06 Jun 2014, at 14:27, Maxim Konovalov ma...@nginx.com wrote: [...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. Отличная новость в пятницу, спасибо! Nginx 1.7.2 содержит именно этот багфикс? Не содержит. -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
[...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 06 Jun 2014, at 14:27, Maxim Konovalov ma...@nginx.com wrote: [...] начал ловить те же баги на не пропатченном Nginx на другом сервере с меньшей нагрузкой, этот патч в опен-сорсе очень бы не помешал! Код в процессе внутреннего ревью. Отличная новость в пятницу, спасибо! -- Maxim Konovalov http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 27 May 2014, at 12:53, Валентин Бартенев vb...@nginx.com wrote: On Tuesday 27 May 2014 12:40:35 Anatoly Mikhailov wrote: [..] Валентин, пока подходящее решение не будет найдено, есть планы выложить текущий патч сюда http://nginx.org/patches/ ? Это было бы очень удобно. ok http://nginx.org/patches/patch.spdy_upstream_fix.txt спасибо! соберу на тестовом сервере и проверю как система себя ведет с этим патчем, если не секрет, в коммерческий релиз Nginx этот патч тоже пока не попал? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 29 May 2014, at 14:36, Валентин Бартенев vb...@nginx.com wrote: On Thursday 29 May 2014 12:49:28 Anatoly Mikhailov wrote: On 27 May 2014, at 12:53, Валентин Бартенев vb...@nginx.com wrote: On Tuesday 27 May 2014 12:40:35 Anatoly Mikhailov wrote: [..] Валентин, пока подходящее решение не будет найдено, есть планы выложить текущий патч сюда http://nginx.org/patches/ ? Это было бы очень удобно. ok http://nginx.org/patches/patch.spdy_upstream_fix.txt спасибо! соберу на тестовом сервере и проверю как система себя ведет с этим патчем, если не секрет, в коммерческий релиз Nginx этот патч тоже пока не попал? Пакеты для nginx plus давно собираются с патчем. Таким образом, там проблем наблюдаться не должно. Валентин, патч решил проблему, спасибо! Будем ждать данный патч в опен-сорс версии Nginx! -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On 26 May 2014, at 13:27, Валентин Бартенев vb...@nginx.com wrote: On Monday 26 May 2014 10:53:49 Anatoly Mikhailov wrote: On 23 May 2014, at 13:36, Валентин Бартенев vb...@nginx.com wrote: On Friday 23 May 2014 11:54:11 Anatoly Mikhailov wrote: Наткнулся на проблему, с которой, похоже, уже разобрались http://trac.nginx.org/nginx/ticket/428 Вопрос - когда патч планируется внести в релиз? В тикете на этот вопрос есть ответ: данный патч вносить не планируется. Другое решение - когда руки дойдут. И надеюсь, что скоро это случится. Валентин, в тикете также обсудили, что данное поведение не воспроизводится при отключенном SPDY, таким образом, это похоже на баг. Подобная проблема с closed connection была в SPDY модуле некоторое время назад и без кэширования и она была решена. Данное поведение воспроизводится в любом случае. Разница лишь в том, что в случае http оно не наносит вреда, а лишь приводит к неоптимальному поведению - закрытию потенциально keepalive соединения, что допустимо. В случае SPDY это приводит к негативным последствиям и разумеется для SPDY это баг - с этим никто не спорит. Может все таки данный патч (кэширование + SPDY) планируется принять в релиз? Это не зависит от моей воли и желания. Два предложенных решения (наиболее простое из них в тикете) не понравились ревьюверу, а над третьим пока не думал. Валентин, пока подходящее решение не будет найдено, есть планы выложить текущий патч сюда http://nginx.org/patches/ ? Это было бы очень удобно. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On Tuesday 27 May 2014 12:40:35 Anatoly Mikhailov wrote: [..] Валентин, пока подходящее решение не будет найдено, есть планы выложить текущий патч сюда http://nginx.org/patches/ ? Это было бы очень удобно. ok http://nginx.org/patches/patch.spdy_upstream_fix.txt -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On Monday 26 May 2014 10:53:49 Anatoly Mikhailov wrote: On 23 May 2014, at 13:36, Валентин Бартенев vb...@nginx.com wrote: On Friday 23 May 2014 11:54:11 Anatoly Mikhailov wrote: Наткнулся на проблему, с которой, похоже, уже разобрались http://trac.nginx.org/nginx/ticket/428 Вопрос - когда патч планируется внести в релиз? В тикете на этот вопрос есть ответ: данный патч вносить не планируется. Другое решение - когда руки дойдут. И надеюсь, что скоро это случится. Валентин, в тикете также обсудили, что данное поведение не воспроизводится при отключенном SPDY, таким образом, это похоже на баг. Подобная проблема с closed connection была в SPDY модуле некоторое время назад и без кэширования и она была решена. Данное поведение воспроизводится в любом случае. Разница лишь в том, что в случае http оно не наносит вреда, а лишь приводит к неоптимальному поведению - закрытию потенциально keepalive соединения, что допустимо. В случае SPDY это приводит к негативным последствиям и разумеется для SPDY это баг - с этим никто не спорит. Может все таки данный патч (кэширование + SPDY) планируется принять в релиз? Это не зависит от моей воли и желания. Два предложенных решения (наиболее простое из них в тикете) не понравились ревьюверу, а над третьим пока не думал. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SPDY вместе с включенным proxy_cache_bypass (#428)
Наткнулся на проблему, с которой, похоже, уже разобрались http://trac.nginx.org/nginx/ticket/428 Вопрос - когда патч планируется внести в релиз? Анатолий ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY вместе с включенным proxy_cache_bypass (#428)
On Friday 23 May 2014 11:54:11 Anatoly Mikhailov wrote: Наткнулся на проблему, с которой, похоже, уже разобрались http://trac.nginx.org/nginx/ticket/428 Вопрос - когда патч планируется внести в релиз? В тикете на этот вопрос есть ответ: данный патч вносить не планируется. Другое решение - когда руки дойдут. И надеюсь, что скоро это случится. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: баг SPDY
On Wednesday 14 August 2013 12:29:10 Илья Шипицин wrote: Добрый день! мы налетели на забавную ситуацию, как оказалось, Chrome и nginx по-разному смотрят на стандарты SPDY. Если отправлять пустой хедер, то Chrome считает, что это корректно и отправляет, nginx же считает, что некорректно и режет. для разбора полетов сделали два стенда https://spdy2.skbkontur.ru https://spdy3.skbkontur.ru (тут для сравнения поднят node.js) учитывая долю Chrome среди браузеров, надо что-то с этим делать. Люди из Google сами в протоколе эту ситуацию явно прописали, даже указали, какую ошибку MUST возвращать сервер. The length of each name and value must be greater than zero. A receiver of a zero-length name or value must send a RST_STREAM with code PROTOCOL error. http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-HEADERS Предлагаю сообщить о баге в Chrome. Разработчики Firefox и Opera читали спецификацию и ведут себя корректно. SPDY draft. 3 предписывает то же самое: A recipient of a zero-length name MUST issue a stream error (Section 2.4.2) with the status code PROTOCOL_ERROR for the stream-id. https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.10 -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: баг SPDY
On Wednesday 14 August 2013 13:59:34 Илья Шипицин wrote: Валентин, в Google я обязательно сообщу. Для этого в том числе и создавался стенд. слишком много нам крови попортила эта бага, чтобы сейчас отступать. я понимаю вашу реакцию, думаю, в дальнейшем есть шансы на послабление бескомпромиссной позиции WONTFIX. для сравнения тот же gzip_disable msie6 вполне можно было не делать, а сказать проблема Майкрософт, браузер же честно говорит Accept-Encoding: gzip, вот мы и отдаем ему gzip. [..] Я не писал про WONTFIX. Не вижу больших проблем с пропуском заголовков с пустым значением. -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: баг SPDY
учитывая ситуацию 1) сколько в мире инсталировано браузеров Chrome 2) отсутствия негативных последствий пропуска пустого хедера (они вообще могут быть ?) наверное, логично просто пропускать пустой хедер. 14 августа 2013 г., 16:22 пользователь Валентин Бартенев vb...@nginx.com написал: On Wednesday 14 August 2013 13:59:34 Илья Шипицин wrote: Валентин, в Google я обязательно сообщу. Для этого в том числе и создавался стенд. слишком много нам крови попортила эта бага, чтобы сейчас отступать. я понимаю вашу реакцию, думаю, в дальнейшем есть шансы на послабление бескомпромиссной позиции WONTFIX. для сравнения тот же gzip_disable msie6 вполне можно было не делать, а сказать проблема Майкрософт, браузер же честно говорит Accept-Encoding: gzip, вот мы и отдаем ему gzip. [..] Я не писал про WONTFIX. Не вижу больших проблем с пропуском заголовков с пустым значением. -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: баг SPDY
On Wednesday 14 August 2013 14:31:38 Илья Шипицин wrote:
учитывая ситуацию
1) сколько в мире инсталировано браузеров Chrome
2) отсутствия негативных последствий пропуска пустого хедера (они
вообще могут быть ?)
наверное, логично просто пропускать пустой хедер.
[..]
Можете опробовать:
diff -r 7094bd12c1ff src/http/ngx_http_spdy.c
--- a/src/http/ngx_http_spdy.c Tue Aug 06 19:58:40 2013 +0400
+++ b/src/http/ngx_http_spdy.c Wed Aug 14 14:41:13 2013 +0400
@@ -2001,10 +2001,6 @@ ngx_http_spdy_parse_header(ngx_http_requ
len = ngx_spdy_frame_parse_uint16(p);
-if (!len) {
-return NGX_ERROR;
-}
-
p += NGX_SPDY_NV_VLEN_SIZE;
r-header_end = p + len;
--
Валентин Бартенев
http://nginx.org/en/donation.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Balancing, SPDY, upstream, pagespeed
Добрый день! Нужна (платная) консультация знающего системного администратора / архитектора на тему, что и как нужно развернуть на серверах, чтобы заработала балансировка нагрузки, синхронизация файлов и проксирование запросов. Серверов от 20, 2 узла. Просьба писать на n...@webo.name Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239841,239841#msg-239841 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SPDY troubles
Добрый день! Использую nginx-1.4.1 на FreeBSD-9-STABLE, OpenSSL-1.0.1 из портов. Собираю nginx из портов с поддержкой SPDY. При добавлении 'spdy' в директиве listen, в error_log появляется много записей вида: 2013/06/04 18:01:32 [alert] 7681#0: kevent() error on 93 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:37 [alert] 7676#0: kevent() error on 57 filter:-2 flags:4000 (2: No such file or directory) Что это может означать? Спасибо. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY troubles
On 04.06.2013, at 18:22, Валентин Бартенев vb...@nginx.com wrote: On Tuesday 04 June 2013 18:06:18 Dmitry Sivachenko wrote: Добрый день! Использую nginx-1.4.1 на FreeBSD-9-STABLE, OpenSSL-1.0.1 из портов. Собираю nginx из портов с поддержкой SPDY. При добавлении 'spdy' в директиве listen, в error_log появляется много записей вида: 2013/06/04 18:01:32 [alert] 7681#0: kevent() error on 93 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:37 [alert] 7676#0: kevent() error on 57 filter:-2 flags:4000 (2: No such file or directory) Что это может означать? Сторонние модули используются? Из сторонних -- echo и lua. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY troubles
On Tuesday 04 June 2013 18:26:35 Dmitry Sivachenko wrote: On 04.06.2013, at 18:22, Валентин Бартенев vb...@nginx.com wrote: On Tuesday 04 June 2013 18:06:18 Dmitry Sivachenko wrote: Добрый день! Использую nginx-1.4.1 на FreeBSD-9-STABLE, OpenSSL-1.0.1 из портов. Собираю nginx из портов с поддержкой SPDY. При добавлении 'spdy' в директиве listen, в error_log появляется много записей вида: 2013/06/04 18:01:32 [alert] 7681#0: kevent() error on 93 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:36 [alert] 7677#0: kevent() error on 69 filter:-2 flags:4000 (2: No such file or directory) 2013/06/04 18:01:37 [alert] 7676#0: kevent() error on 57 filter:-2 flags:4000 (2: No such file or directory) Что это может означать? Сторонние модули используются? Из сторонних -- echo и lua. Проверьте, воспроизводится ли проблема без сторонних модулей. В частности, lua-модуль известен как несовместимый со spdy. -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY troubles
On 04.06.2013, at 18:49, Валентин Бартенев vb...@nginx.com wrote: Проверьте, воспроизводится ли проблема без сторонних модулей. В частности, lua-модуль известен как несовместимый со spdy. На тестовой машине ошибок не было и в этой конфигурации. Отключить lua в продакшене не представляется возможным, сайт работать не будет. Там какая-то фундаментальная несовместимость или можно надеяться что через некоторое время lua станет совместим со spdy? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY troubles
On Tuesday 04 June 2013 18:56:50 Dmitry Sivachenko wrote: On 04.06.2013, at 18:49, Валентин Бартенев vb...@nginx.com wrote: Проверьте, воспроизводится ли проблема без сторонних модулей. В частности, lua-модуль известен как несовместимый со spdy. На тестовой машине ошибок не было и в этой конфигурации. Отключить lua в продакшене не представляется возможным, сайт работать не будет. Там какая-то фундаментальная несовместимость или можно надеяться что через некоторое время lua станет совместим со spdy? Это вопрос к автору модуля. По крайней мере два тикета на данный момент открыто на тему spdy: https://github.com/chaoslawful/lua-nginx-module/issues/173 https://github.com/chaoslawful/lua-nginx-module/issues/142 плюс ещё периодически люди жаловались в разных местах. Не знаю, насколько это актуально сейчас, но lua модуль лезет во внутренние структуры и делает кучу всего, включая и то, что никогда не предусматривалось, так что дебаг какой-либо проблемы с ним практически невозможен, зато можно ожидать различные спецэффекты. Почти любая ошибка с легкостью может быть вызвана сторонним модулем, который по объему кода составляет четвертую часть всего nginx-а. Попробуйте снять дебаг лог с данной ошибкой. http://nginx.org/ru/docs/debugging_log.html Это минимум, что требуется, чтобы как-то помочь. -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
SPDY over HTTP
Добрый день. Тут спор возник с коллегой. SPDY работает только поверх SSL или через HTTP тоже возможно? Сейчас понятное дело, что только по SSL. А вообще как оно должно быть по стандарту? Вроде как там нет четкой привязки к SSL. Ткните носом как правильно, плз. -- С уважением, Дмитрий Лялюев тел. +380 (66) 532-29-62 Все контакты для связи на http://lyalyuev.info ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SPDY over HTTP
On Friday 31 May 2013 15:09:05 Дмитрий Лялюев wrote: Добрый день. Тут спор возник с коллегой. SPDY работает только поверх SSL или через HTTP тоже возможно? Сейчас понятное дело, что только по SSL. А вообще как оно должно быть по стандарту? Вроде как там нет четкой привязки к SSL. Ткните носом как правильно, плз. SPDY не работает по HTTP по той же причине, почему он не работает по HTTPS. Но я догадываюсь, что вопрос был о том, работает ли SPDY по plain TCP. Об этом ликбез уже был, смотрите тут: http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050114.html -- Валентин Бартенев http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
