Hi,
websocket over http2 is defined in RFC8441, chrome and firefox support it.
https://chromestatus.com/feature/6251293127475200
websocket over http3 is defined in RFC9220, neither of chrome nor
firefox support it.
https://chromestatus.com/feature/5080537855688704
Is there any plan to support
Hello!
On Thu, Dec 28, 2023 at 11:21:55AM +0300, Evgeniy Berdnikov wrote:
> On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:
> > nginx: [warn] the "listen ... http2" directive is deprecated, use the
> > "http2" directive instead in /etc/nginx/sites-enabl
Hello!
On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:
> Здравствуйте!
>
> Я про
>
> nginx: [warn] the "listen ... http2" directive is deprecated, use the
> "http2" directive instead in /etc/nginx/sites-enabled/...:152
>
>
> Надо
On Thu, Dec 28, 2023 at 10:07:41AM +0200, Иван wrote:
> nginx: [warn] the "listen ... http2" directive is deprecated, use the
> "http2" directive instead in /etc/nginx/sites-enabled/...:152
>
>
> Надо http2 из параметра директивы listen перенести в отде
Здравствуйте!
Я про
nginx: [warn] the "listen ... http2" directive is deprecated, use the
"http2" directive instead in /etc/nginx/sites-enabled/...:152
Надо http2 из параметра директивы listen перенести в отдельную
http2 on;
У меня несколько десятков блоков serve
User Yaroslav Zhuravlev
# Date 1686668685 -3600
# Tue Jun 13 16:04:45 2023 +0100
# Node ID b42c78a25477b40c78c048cd3d8f44421e814fca
# Parent 2fa6471cd138071038f055031a7a379a7e9ab108
Documented the http2 directive.
diff --git a/xml/en/docs/http/ngx_http_core_module.xml
b/xml/en/docs/http/ngx_http
Hello!
On Tue, Jun 13, 2023 at 02:56:50PM +0100, Yaroslav Zhuravlev wrote:
> @@ -55,7 +55,9 @@
>
>
> server {
> -listen 443 ssl http2;
> +listen 443 ssl;
> +
> +http2 on;
>
> ssl_certificate server.crt;
> ssl_certificate_
Date 1686664161 -3600
> # Tue Jun 13 14:49:21 2023 +0100
> # Node ID d0b3b7889bfa45ce03845acdc51919463f455874
> # Parent 2fa6471cd138071038f055031a7a379a7e9ab108
> Documented the http2 directive.
>
> diff --git a/xml/en/docs/http/ngx_http_core_module.xml
> b/xml
# Parent 2fa6471cd138071038f055031a7a379a7e9ab108
Documented the http2 directive.
diff --git a/xml/en/docs/http/ngx_http_core_module.xml b/xml/en/docs/http/ngx_http_core_module.xml
--- a/xml/en/docs/http/ngx_http_core_module.xml
+++ b/xml/en/docs/http/ngx_http_core_module.xml
@@ -10,7 +10,7
details: https://hg.nginx.org/nginx/rev/08ef02ad5c54
branches:
changeset: 9119:08ef02ad5c54
user: Roman Arutyunyan
date: Tue May 16 16:30:08 2023 +0400
description:
HTTP/2: "http2" directive.
The directive enables HTTP/2 in the current server. The previous way to
enable
> >> +++ b/src/http/ngx_http_request.c
> > > > >> @@ -318,12 +318,6 @@ ngx_http_init_connection(ngx_connection_
> > > > >> rev->handler = ngx_http_wait_request_handler;
> > > > >> c-&
ttp/ngx_http_request.c b/src/http/ngx_http_request.c
> > > >> --- a/src/http/ngx_http_request.c
> > > >> +++ b/src/http/ngx_http_request.c
> > > >> @@ -318,12 +318,6 @@ ngx_http_init_connection(ngx_connection_
> > > >> rev->handler
/http/ngx_http_request.c
> > >> @@ -318,12 +318,6 @@ ngx_http_init_connection(ngx_connection_
> > >> rev->handler = ngx_http_wait_request_handler;
> > >> c->write->handler = ngx_http_empty_handler;
> > >>
> > >> -#if (NGX_HTTP_V2)
bd1460c314c93
> # Parent d8272b84031bea1940ef8a5b8e2f79ec6a2dcfc1
> HTTP/2: "http2" directive.
>
> The directive enables HTTP/2 in the current server. The previous way to
> enable HTTP/2 via "listen ... http2" is now deprecated. The new approach
> allows to share HTTP/2 and HTTP/0.9
> Observed nginx's version 1.22.1 questionable behaviour with two virtual
> hosts, one with H2 - enabled, second without http2 support.
> Both on the same IP and port, with different domain names/server names.
>
> Is it a bug, feature, my misconfiguration or just not needed by any
Hello,
Observed nginx's version 1.22.1 questionable behaviour with two virtual
hosts, one with H2 - enabled, second without http2 support.
Both on the same IP and port, with different domain names/server names.
When browsers make requests to a second domain, h2 being ALPN-negotiated,
and data
Hello!
On Wed, May 24, 2023 at 01:07:00AM +0300, Andrey Kulikov wrote:
> Observed nginx's version 1.22.1 questionable behaviour with two virtual
> hosts, one with H2 - enabled, second without http2 support.
> Both on the same IP and port, with different domain names/server names.
> W
Hello,
Observed nginx's version 1.22.1 questionable behaviour with two virtual
hosts, one with H2 - enabled, second without http2 support.
Both on the same IP and port, with different domain names/server names.
When browsers make requests to a second domain, h2 being ALPN-negotiated,
and data
Hello,
Yes your solution did work with version:
nginx version: nginx/1.18.0
built with LibreSSL 3.3.2
I removed http2 from all vhost effectively disabling it on the server and it
works fine. I wonder if I even need it for anything :)
But as you said this might not even be an option
l -v --anyauth -k https://app.test.lan/cgi-bin/page.pl
>
> I get:
>
> http2 error: Invalid HTTP header field was received: frame type:
> 1, stream: 3, name: [defined(%hash) is deprecated at page.pl
> line 14.], value: []
>
> However if I define http1.1 it works fin
Hello List,
I have a setup where I put an ancient host running a perl-cgi app behind an
nginx reverse proxy.
The http reverse proxy works fine however if I try:
curl -v --anyauth -k https://app.test.lan/cgi-bin/page.pl
I get:
http2 error: Invalid HTTP header field was received: frame type
_request_handler;
> >> c->write->handler = ngx_http_empty_handler;
> >>
> >> -#if (NGX_HTTP_V2)
> >> -if (hc->addr_conf->http2) {
> >> -rev->handler = ngx_http_v2_init;
> >> -}
> >> -#endif
> >>
>> +++ b/src/http/ngx_http_request.c
>> @@ -318,12 +318,6 @@ ngx_http_init_connection(ngx_connection_
>> rev->handler = ngx_http_wait_request_handler;
>> c->write->handler = ngx_http_empty_handler;
>>
>> -#if (NGX_HTTP_V2)
>> -if (hc
_
> rev->handler = ngx_http_wait_request_handler;
> c->write->handler = ngx_http_empty_handler;
>
> -#if (NGX_HTTP_V2)
> -if (hc->addr_conf->http2) {
> -rev->handler = ngx_http_v2_init;
> -}
> -#endif
&
3 +0400
> > # Branch quic
> > # Node ID 735f9e501922e4b0a1b20730d62bac35ea398336
> > # Parent 38eec3d9f2c0d2e6d041efe3ee6d9c1618d8f1e6
> > HTTP/2: "http2" directive.
> >
> > The directive enables HTTP/2 in the current server. The previous way to
> > en
2e6d041efe3ee6d9c1618d8f1e6
> HTTP/2: "http2" directive.
>
> The directive enables HTTP/2 in the current server. The previous way to
> enable HTTP/2 via "listen ... http2" is now deprecated. The new approach
> allows to share HTTP/2 and HTTP/0.9-1.1 on the same
> On 7 Feb 2023, at 18:50, Roman Arutyunyan wrote:
>
> Hi,
>
> Updated the patches based on latest comments.
Looks good to me.
--
Sergey Kandaurov
___
nginx-devel mailing list
nginx-devel@nginx.org
# HG changeset patch
# User Roman Arutyunyan
# Date 1675781276 -14400
# Tue Feb 07 18:47:56 2023 +0400
# Branch quic
# Node ID 735f9e501922e4b0a1b20730d62bac35ea398336
# Parent 38eec3d9f2c0d2e6d041efe3ee6d9c1618d8f1e6
HTTP/2: "http2" directive.
The directive enables HTTP/2 in t
Hi,
Updated the patches based on latest comments.
--
Roman Arutyunyan
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
6:49:50 2023 +0400
> > # Branch quic
> > # Node ID 139b348815b3f19753176988f06b590a3e0af4c0
> > # Parent 2fcc1c60be1c89aad5464bcc06f1189d1adc885a
> > HTTP/2: "http2" directive.
> >
> > The directive enables HTTP/2 in the current server. The previou
3 +0400
> > # Branch quic
> > # Node ID 139b348815b3f19753176988f06b590a3e0af4c0
> > # Parent 2fcc1c60be1c89aad5464bcc06f1189d1adc885a
> > HTTP/2: "http2" directive.
> >
> > The directive enables HTTP/2 in the current server. The previous way to
> > ena
9aad5464bcc06f1189d1adc885a
> HTTP/2: "http2" directive.
>
> The directive enables HTTP/2 in the current server. The previous way to
> enable HTTP/2 via "listen ... http2" is now deprecated.
>
> diff --git a/src/http/modules/ngx_http_ssl_module.c
&g
e0af4c0
> # Parent 2fcc1c60be1c89aad5464bcc06f1189d1adc885a
> HTTP/2: "http2" directive.
>
> The directive enables HTTP/2 in the current server. The previous way to
> enable HTTP/2 via "listen ... http2" is now deprecated.
It might be a good idea to describe here how it works, notably
# HG changeset patch
# User Roman Arutyunyan
# Date 1675255790 -14400
# Wed Feb 01 16:49:50 2023 +0400
# Branch quic
# Node ID 139b348815b3f19753176988f06b590a3e0af4c0
# Parent 2fcc1c60be1c89aad5464bcc06f1189d1adc885a
HTTP/2: "http2" directive.
The directive enables HTTP/2 in t
Hi,
Updates in this series:
- Detect HTTP-level redirects to servers where the negotiated protocol is not
available. Now 421 is returned.
- Retained old http3 configuration for compatibility.
- Reimplemented the http2 patch. Now http2 preface is read in
ngx_http_wait_request_handler
a9bb2db
> # Parent 555913c358221f647bbace26165bef5eb614add4
> HTTP/2: "http2" directive.
>
> The directive enables HTTP/2 in the current server. The previous way to
> enable HTTP/2 via "listen ... http2" is now deprecated.
In no particular order:
- The ngx_http_try_v2() shoul
# HG changeset patch
# User Roman Arutyunyan
# Date 1674649725 -14400
# Wed Jan 25 16:28:45 2023 +0400
# Branch quic
# Node ID 819737783463d7e38ea80109a976db1d3a9bb2db
# Parent 555913c358221f647bbace26165bef5eb614add4
HTTP/2: "http2" directive.
The directive enables HTTP/2 in t
Hi,
These patches change http2 and http3 configurations. Previously, both protocols
were configured by "listen" parameters:
listen 8800 ssl http2;
listen 8443 http3;
The patches introduce new directives for configuring http2 and http3 in server
scope:
server {
liste
Thanks again Maxim. Response inlined.
> On Oct 20, 2022, at 6:43 PM, Maxim Dounin wrote:
>
> Hello!
>
> On Thu, Oct 20, 2022 at 06:09:11PM -0700, Jojy Varghese via nginx-devel wrote:
>
> [...]
>
>>> If you think that nginx does something wrong, you may want to
>>> elaborate on the details
Hello!
On Thu, Oct 20, 2022 at 06:09:11PM -0700, Jojy Varghese via nginx-devel wrote:
[...]
> > If you think that nginx does something wrong, you may want to
> > elaborate on the details of the incorrect behaviour you observe
> > (as well as why you think it's incorrect, and how would you
Hi Maxim
Thanks for the response. Answers inline.
-jojy
> On Oct 20, 2022, at 2:19 PM, Maxim Dounin wrote:
>
> Hello!
>
> On Thu, Oct 20, 2022 at 10:51:06AM -0700, Jojy Varghese via nginx-devel wrote:
>
>> Hi
>> We noticed that the Http2 idle flag
>>
Hello!
On Thu, Oct 20, 2022 at 10:51:06AM -0700, Jojy Varghese via nginx-devel wrote:
> Hi
> We noticed that the Http2 idle flag
> (https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.h#L126)
> is initialized to `1`
> (https://github.com/nginx/nginx/blob/
Hi
We noticed that the Http2 idle flag
(https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.h#L126) is
initialized to `1`
(https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.c#L335) but
not reset by the http2 state machine. It also looks like Nginx does
для истории - хром и сафари пытаются переиспользовать конекшин
если отдавать 421, то хром переподключается (как и ожидается), а сафари
превращается в тыкву.
вт, 1 дек. 2020 г. в 18:43, Maxim Dounin :
> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020
нельзя сказать, чтобы с вебсокетами или http2 всё было прямо печально.
обе годные технологии с какими-то небольшими изъянами проектирования, не
более
ср, 2 дек. 2020 г. в 09:37, Aln Kapa :
> Понял.
> А ещё вопрос, вот сейчас http3 ждём там все также печально?
>
> вт, 1 дек. 2020 г.,
Понял.
А ещё вопрос, вот сейчас http3 ждём там все также печально?
вт, 1 дек. 2020 г., 21:48 Maxim Dounin :
> Hello!
>
> On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:
>
> > От это поворот!
> > без tls и на каждый коннект отдельное соединение.
>
> Про "без tls" - это уж как
вспомнил. мы проводили исследование на то, пользуются ли клиенты SNI.
в принципе, на вайлдкардовых сертах, как оказалось, можно работать и без
SNI.
некоторые случаи мы идентифицировали, это клиенты с определенными билдами
КриптоПро (как-то оно афектит даже RSA криптографию)
я к чему. в
Hello!
On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:
> От это поворот!
> без tls и на каждый коннект отдельное соединение.
Про "без tls" - это уж как сконфигурите. А то, что соединение
это, ВНЕЗАПНО, соединение - ну да, так уж получилось.
> А sse работает так же?
Если под SSE
От это поворот!
без tls и на каждый коннект отдельное соединение. А sse работает так же?
вт, 1 дек. 2020 г., 20:16 Maxim Dounin :
> Hello!
>
> On Tue, Dec 01, 2020 at 06:52:47PM +0300, Aln Kapa wrote:
>
> > А вот такое поведение? В какой-то момент chrome перестает что либо
> получать
> > по
Hello!
On Tue, Dec 01, 2020 at 06:52:47PM +0300, Aln Kapa wrote:
> А вот такое поведение? В какой-то момент chrome перестает что либо получать
> по websocket, если открыть несколько вкладок на разные сайты с одним ip.
Вебсокеты не ходят по HTTP/2, стандарт не предусматривает
(отдельно сбоку их
я бы не стал смешивать всё в кучу. вебсокеты это скриптовые штуки, сами
себя они не читают.
а приоритет неактивных вкладок понижается.
это лишь гипотеза. но тем не менее
вт, 1 дек. 2020 г. в 20:53, Aln Kapa :
> А вот такое поведение? В какой-то момент chrome перестает что либо
> получать по
А вот такое поведение? В какой-то момент chrome перестает что либо получать
по websocket, если открыть несколько вкладок на разные сайты с одним ip.
вт, 1 дек. 2020 г., 2:11 Maxim Dounin :
> Hello!
>
> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > может кто
вт, 1 дек. 2020 г. в 18:43, Maxim Dounin :
> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в
вт, 1 дек. 2020 г. в 18:13, Maxim Dounin :
> Hello!
>
> On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> >
> > > Hello!
> > >
> > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > >
> > > > привет!
> > > >
> > > >
Hello!
On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
>
> > Hello!
> >
> > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> >
> > > привет!
> > >
> > > может кто сталкивался, и знает, что с этим можно сделать.
> > >
вт, 1 дек. 2020 г. в 04:11, Maxim Dounin :
> Hello!
>
> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > может кто сталкивался, и знает, что с этим можно сделать.
> > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > домены разные, каждый со
Hello!
On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> привет!
>
> может кто сталкивался, и знает, что с этим можно сделать.
> ситуация - хостинг высокой плотности, на одном IP много доменов.
> домены разные, каждый со своей бизнес логикой.
>
> у Chrome включается какая-то
привет!
может кто сталкивался, и знает, что с этим можно сделать.
ситуация - хостинг высокой плотности, на одном IP много доменов.
домены разные, каждый со своей бизнес логикой.
у Chrome включается какая-то оптимизация, и типа "ну раз IP один, то я
буду весь трафик гонять через одно tcp
53c2d008e
> HTTP/2: premalloc http2 recv_buffer in init_conf
>
> There is no need to check if h2mcf->recv_buffer malloced every time.
>
> diff -r 87d2ea860f38 -r 1532a8fca7b2 src/http/v2/ngx_http_v2.c
> --- a/src/http/v2/ngx_http_v2.cMon Sep 10 18:57:39 2018 +0300
> +++ b/
# HG changeset patch
# User Kasei Wang
# Date 1599480224 -28800
# Mon Sep 07 20:03:44 2020 +0800
# Node ID 1532a8fca7b24c3c3aa5cddd3362402d15f57a4f
# Parent 87d2ea860f380dc8418c97c0163412f53c2d008e
HTTP/2: premalloc http2 recv_buffer in init_conf
There is no need to check if h2mcf
Илья Шипицин Wrote:
---
> у вас же должны быть логи по html страницам и по css-файлам.
> посмотрите на них.
> если
>
> а) у вас хорошее кеширование (т.е. ноль 304-х)
> б) количество ответов css соответствует количеству отданных html страниц
>
>
> насчет действительно связанных css и js - в принципе можно их
> эмбедить
> прямо в html разметку. и отдавать вместе с основной страницей.
> тот же push.
Только без потенциального выигрыша в попадании из push-кэша в основной с
возможностью отказаться от получения ресурса в дальнейшем.
А если
S.A.N Wrote:
---
> > Решение о push'е принимается при генерации HTML-ответа за запрос к
> > странице.
> > В этот момент доступны If-None-Match и/или If-Modified-Since только
> > самой страницы и странно ориентироваться на них, так как они ничего
Hello!
On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно
gt; > данные уже летят по сети и отъедают пропускную способность канала,
> > > это обстоятельство может навредить желанию загрузить все причандалы
> > > к странице побыстрее.
> > >
> > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
&
т навредить желанию загрузить все причандалы
> > к странице побыстрее.
> >
> > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
> > профит от сложной и очень тяжёлой технологии". И push в том ряду.
> >
>
>
> http2 решает искуст
аранее.
> А если нет, то к тому моменту, когда клиент сможет отклонить push,
> данные уже летят по сети и отъедают пропускную способность канала,
> это обстоятельство может навредить желанию загрузить все причандалы
> к странице побыстрее.
>
> Вообще, почти про всё связанно
ь push,
данные уже летят по сети и отъедают пропускную способность канала,
это обстоятельство может навредить желанию загрузить все причандалы
к странице побыстрее.
Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
профит от сложной и очень тяжёлой технологии". И
> то выигрыш будет отрицательный
у меня эта фраза вызывает когнитивный диссонанс
On Wed, Apr 29, 2020 at 8:41 PM Илья Шипицин wrote:
>
>
> ср, 29 апр. 2020 г. в 22:26, gz :
>
>> > > Востребованные ресурсы из push-кэша переходят в основной и будут
>> > > использованы для следующих страниц.
>> >
ср, 29 апр. 2020 г. в 22:26, gz :
> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента
> > Востребованные ресурсы из push-кэша переходят в основной и будут
> > использованы для следующих страниц.
> > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> в
> > кэше.
> > В крайнем случае несложно пометить клиента стандартным способом
> через
> > cookie.
>
> Проблема
> Советую смотреть не на куки, а на наличия клиенских заголовков -
> If-None-Match и/или If-Modified-Since, только при отсутствии или не
> валидности данных заголовков делать push.
> Из нашего опыта - push полезен только для клиентов у которых нет
> валидного кеша, в этом случаи вы получите не
Hello!
On Tue, Apr 28, 2020 at 02:19:48PM +0200, Valery Kholodkov wrote:
> On 27-04-2020 22:29, gz wrote:
> > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> >
> > Не совсем понимаю какие выводы делают авторы.
>
> Мне, кроме того, и непонятно где автор взял
On 27-04-2020 22:29, gz wrote:
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
Не совсем понимаю какие выводы делают авторы.
Мне, кроме того, и непонятно где автор взял исходные данные.
--
Val
___
nginx-ru mailing list
> на ресурсы для предзагрузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > >
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > >
> > > Практически не проверял, но здра
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.
Советую смотреть не на куки, а на наличия клиенских заголовков -
If-None-Match и/или If-Modified-Since, только при отсутствии или не
валидности данных заголовков делать push.
Из нашего опыта - push полезен только
грузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > >
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > >
> > > Практически не проверял, но здравый смысл подсказывает, что даж
грузки на http2_push указанных
> ресурсов.
> > >
> > > А вы пробовали тестировать, что вы получите на выходе?
> >
> > Практически не проверял, но здравый смысл подсказывает, что даже в
> рамках
> > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
бы перейти с предзагрузки на http2_push указанных ресурсов.
> >
> > А вы пробовали тестировать, что вы получите на выходе?
>
> Практически не проверял, но здравый смысл подсказывает, что даже в рамках
> HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум
&
ировать, что вы получите на выходе?
Практически не проверял, но здравый смысл подсказывает, что даже в рамках
HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум
один запрос на получение ресурсов, объявленных в .
> Имеющиеся исследования про эффективность HTTP/2 push позволяю
Hello!
On Mon, Apr 27, 2020 at 09:33:08AM -0400, gz wrote:
> В HTML страницы бэкендом выдаются элементы с указанием
> на ресурсы для предзагрузки.
> Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
А вы пробовали тестировать, что вы получите на выходе? Имеющиеся
В HTML страницы бэкендом выдаются элементы с указанием
на ресурсы для предзагрузки.
Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
Казалось бы, нет проблемы перейти на заголовок Link, который модулем
ngx_http_v2_module при http2_push_preload on будет преобразован в push'и.
Hi,
it seems that macOS still has an issue with the proper handling of RST_STREAM.
Since NGINX 1.18.0 the proper handling of RST_STREAM is re-enabled in this
commit:
https://hg.nginx.org/nginx/rev/2e61e4b6bcd9
I used git bisect to track this down. Our server mainly handles basic-auth
Hi,
I am trying to understand how the modules work when dealing with http2
traffic? Trying to find any documentation or any other info that will
tells me how a module should behave when handling http2 traffic. I am
assuming the actual http2 protocol parsing is done by the http2 module. How
can
Hello everyone.
I need to pass a security audit, For a PCI compliance process.
A scan was performed on my servers and found a vulnerability in nginx
"HTTP2 SETTINGS FRAME Denial of Service"
I upgraded nginx to the latest stable 1.16.1 which supposedly fixes that
issue. s
it is expected to
> > account sending the response to client as well.
>
> thanks Maxim, I see your point.
>
> Anyway, I found some http2 requests have large $request_time in my logs(
> which is unreasonable large), will you be sure that the $request_time in
> http2 proto
t; account sending the response to client as well.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
thanks Maxim, I see your point.
Any
Hello!
On Wed, Jan 22, 2020 at 10:38:42AM -0500, xt3627216 wrote:
[...]
> if stream->queued is true, then ngx_http_free_request will not be called
> immediately, which will result $request_time larger then real request time?
If stream->queued is true, this means that there are unsent
> nginx version: nginx-1.9.5
Have you tried updating to a newer version of nginx? The 1.9 branch is
probably 5 years old...
It looks like the code you mention has changed somewhat, though I
don't know if it has any effect on $request_time.
In our production env， I found that $request_time is very large under
http2 protocol.
by the way, some requests, not every one.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,286797,286798#msg-286798
___
nginx mailing list
nginx
nginx version: nginx-1.9.5
hi，nginx compute $request_time in log phase, which is in
ngx_http_free_request (r) -> ngx_http_log_request(r) -> log_handler(r)
but in http2 world, I see every request closed through
ngx_http_v2_close_stream(stream, rc)
in ngx_http_v2_close_stream
Hmmm, maybe it got packported by Debian...
I think we'll just disable http2 for the time being.
On Tue, 17 Dec 2019 at 09:13, Ruslan Ermilov wrote:
>
> On Mon, Dec 16, 2019 at 05:45:55PM +, Jasper Wallace wrote:
> > We are having intermittent problems uploading fil
On Mon, Dec 16, 2019 at 05:45:55PM +, Jasper Wallace wrote:
> We are having intermittent problems uploading files via nginx to a
> flask backend over http2:
>
> 2019/12/16 16:07:08 [debug] 27658#27658: *1 event timer: 3, old:
> 1576512608187, new: 1576512608301
> 2019/12/
We are having intermittent problems uploading files via nginx to a
flask backend over http2:
2019/12/16 16:07:08 [debug] 27658#27658: *1 event timer: 3, old:
1576512608187, new: 1576512608301
2019/12/16 16:07:08 [debug] 27658#27658: *1 http2 idle handler
2019/12/16 16:07:08 [info] 27658#27658: *1
; What confused me is the fact that this is only done in http2 connections...
>
> I really don't know why but all the changes i do in the read_client_request
> handler reflect to the main ngx_http_request_t struct. I thought the code
> was cleaner by having the body read in a fu
I don't know if this is a bug or not but... yes you were right...
All the work should be done in the ngx_http_read_client_request_body
handler, as it does duplicate the r connection to another address
What confused me is the fact that this is only done in http2 connections...
I really don't
Hello!
On Mon, Oct 14, 2019 at 02:41:33PM -0400, Ansuel wrote:
> this is what i have in the module handler function
>
> rc = ngx_http_read_client_request_body(r, ngx_http_test_read_req);
> if (rc != NGX_OK && rc != NGX_AGAIN) {
> return rc;
> }
this is what i have in the module handler function
rc = ngx_http_read_client_request_body(r, ngx_http_test_read_req);
if (rc != NGX_OK && rc != NGX_AGAIN) {
return rc;
}
And this is what i have in
ngx_http_test_read_req
char *buffer =
ta in a char buffer
Note that unless you've specifically tuned client_body_buffer_size
and client_max_body_size, there can be in-file buffers in
r->request_body->bufs.
> Aside from the fact that put request body in a buffer is wrong because it
> can became very big...
>
> I notice th
_buf_size(in->buf);
ngx_memcpy(buffer + pos,in->buf->pos,len);
pos += len;
}
To put the data in a char buffer
Aside from the fact that put request body in a buffer is wrong because it
can became very big...
I notice that if i enabl
1 - 100 of 336 matches
Mail list logo
