From xeioex at nginx.com Wed Jun 5 23:04:02 2024 From: xeioex at nginx.com (Dmitry Volyntsev) Date: Wed, 5 Jun 2024 16:04:02 -0700 Subject: NGINX JavaScript (njs) has migrated to Github Message-ID: <00c161a8-b8ff-47c9-a74d-d35426bf03b3@nginx.com> Hello, This week we took the next step in our commitment to the Open Source community by moving the official njs code repository to GitHub (https://github.com/nginx/njs). As part of the move, we have revamped our testing infrastructure and added clearer guidelines around installation, building, and contributing source code. We believe these changes will serve two purposes: 1. Modernize njs by creating a single place for the community to contribute, ask questions, and provide feedback. 2. Underscore our commitment to openness, consistency, transparency, and fairness in our acceptance of contributions. Importantly, these changes do not impact core njs source code, functionality, or license in any way. They simply do a better job at codifying existing guidelines, while providing a modern approach for managing the project and community. Please refer to the following files for more details: README.md https://github.com/nginx/njs/blob/master/README.md Provides basic information on what NJS is, how it is used (including links to sample code & projects), installing, debugging, building from source, etc... CONTRIBUTING.md https://github.com/nginx/njs/blob/master/CONTRIBUTING.md Provides clear guidelines for asking questions, suggesting improvements, and contributing code. You will also find our code and git style guides here. CODE_OF_CONDUCT.md https://github.com/nginx/njs/blob/master/CODE_OF_CONDUCT.md Our pledge, policies, and guidelines for community etiquette, along with enforcement procedures. SECURITY.md https://github.com/nginx/njs/blob/master/SECURITY.md Our security policy, including what constitutes a security concern and procedures for reporting vulnerabilities. SUPPORT.md https://github.com/nginx/njs/blob/master/SUPPORT.md A list of all support resources available to the community. For additional information on F5 NGINX’s commitment to our Open Source projects and communities, please see: https://www.f5.com/company/blog/nginx/meetup-recap-nginxs-commitments-to-the-open-source-community We look forward to your feedback, questions, and contributions as we work together to make njs even faster, more powerful, and feature-rich! From hasan.calisir at psauxit.com Sun Jun 9 19:37:13 2024 From: hasan.calisir at psauxit.com (=?UTF-8?Q?Hasan_=C3=87ALI=C5=9EIR?=) Date: Sun, 09 Jun 2024 22:37:13 +0300 Subject: Cache purge & preload solution on wordpress Message-ID: Hi Nginx Community, I wanted to share a free plugin I developed after struggling with cache purge and preload actions on WordPress. It's a tool that simplifies cache management directly from the wordpress admin dashboard, trying to automate cache preloading and purging with different direct approach, and have some useful features like WP Cron scheduling and REST API support. WordPress Repo: FastCGI Cache Purge and Preload for Nginx [1] GitHub: FastCGI Cache Purge and Preload for Nginx [2] Hope community find it useful, feel free to check it out and you're welcome to contribute. Best, ~Hasan ÇALIŞIR Links: ------ [1] https://wordpress.org/plugins/fastcgi-cache-purge-and-preload-nginx/ [2] https://github.com/psaux-it/nginx-fastcgi-cache-purge-and-preload -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at lagy.org Mon Jun 10 08:56:05 2024 From: me at lagy.org (Martin =?utf-8?Q?Kj=C3=A6r_J=C3=B8rgensen?=) Date: Mon, 10 Jun 2024 10:56:05 +0200 Subject: Custom HTTP protocol response? Message-ID: <877cexi34h.fsf@lagy.org> Hi, I'm experimenting with nginx to have it respond in an incompatible wait to a HTTP client. A normal response would be like the usual: HTTP/1.1 200 OK Content-Type: text/plain ... I would like to modify the HTTP response to this instead, using nginx and perhaps some lua scripting if needed: UNKNOWN 200 OK Content-Type: text/plain ... Is this possible without hacking nginx sources or manipulative intermediate proxies? /Martin From kirill at korins.ky Thu Jun 13 15:05:18 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Thu, 13 Jun 2024 16:05:18 +0100 Subject: Custom HTTP protocol response? In-Reply-To: <877cexi34h.fsf@lagy.org> References: <877cexi34h.fsf@lagy.org> Message-ID: <7d2c8f6a709cfef8@mx2.catap.net> On Mon, 10 Jun 2024 09:56:05 +0100, Martin Kjær Jørgensen via nginx wrote: > > > Is this possible without hacking nginx sources or manipulative intermediate > proxies? > As you may see in ngx_http_header_filter_module.c such string is hardcoded. -- wbr, Kirill From kirill at korins.ky Sat Jun 15 11:02:28 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Sat, 15 Jun 2024 12:02:28 +0100 Subject: Allow response with AD bit in resolver Message-ID: Greetings, Here a trivial patch which allows DNS responses with enabled AD bit from used resolver. Index: src/core/ngx_resolver.c --- src/core/ngx_resolver.c.orig +++ src/core/ngx_resolver.c @@ -1774,7 +1774,7 @@ ngx_resolver_process_response(ngx_resolver_t *r, u_cha (response->nar_hi << 8) + response->nar_lo); /* response to a standard query */ - if ((flags & 0xf870) != 0x8000 || (trunc && tcp)) { + if ((flags & 0xf850) != 0x8000 || (trunc && tcp)) { ngx_log_error(r->log_level, r->log, 0, "invalid %s DNS response %ui fl:%04Xi", tcp ? "TCP" : "UDP", ident, flags); -- wbr, Kirill From lzqhwo at gmail.com Sat Jun 15 12:58:55 2024 From: lzqhwo at gmail.com (Dominic Preston) Date: Sat, 15 Jun 2024 13:58:55 +0100 Subject: How important is the "reuseport" flag for quic? Message-ID: I'm using nginx 1.26.1 from the nginx.org ubuntu repo. I find when I remove the "reuseport" flag from the "listen" directive for my quic port, a lot page assets fail to load, and the browser ultimately falls back to http/2. When I re-add "reuseport", all http/3 requests succeed again. How crucial is "reuseport" when using quic on nginx? Is it normal for things to break badly without it? From mdounin at mdounin.ru Sun Jun 16 01:29:51 2024 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 16 Jun 2024 04:29:51 +0300 Subject: Allow response with AD bit in resolver In-Reply-To: References: Message-ID: Hello! On Sat, Jun 15, 2024 at 12:02:28PM +0100, Kirill A. Korinsky wrote: > Greetings, > > Here a trivial patch which allows DNS responses with enabled AD bit > from used resolver. > > Index: src/core/ngx_resolver.c > --- src/core/ngx_resolver.c.orig > +++ src/core/ngx_resolver.c > @@ -1774,7 +1774,7 @@ ngx_resolver_process_response(ngx_resolver_t *r, u_cha > (response->nar_hi << 8) + response->nar_lo); > > /* response to a standard query */ > - if ((flags & 0xf870) != 0x8000 || (trunc && tcp)) { > + if ((flags & 0xf850) != 0x8000 || (trunc && tcp)) { > ngx_log_error(r->log_level, r->log, 0, > "invalid %s DNS response %ui fl:%04Xi", > tcp ? "TCP" : "UDP", ident, flags); > Looks good to me, pushed with an appropriate commit log, thanks. -- Maxim Dounin http://mdounin.ru/ From jordanc.carter at outlook.com Sun Jun 16 01:34:39 2024 From: jordanc.carter at outlook.com (J Carter) Date: Sun, 16 Jun 2024 02:34:39 +0100 Subject: Custom HTTP protocol response? In-Reply-To: <7d2c8f6a709cfef8@mx2.catap.net> References: <877cexi34h.fsf@lagy.org> <7d2c8f6a709cfef8@mx2.catap.net> Message-ID: Hello, On Thu, 13 Jun 2024 16:05:18 +0100 Kirill A. Korinsky wrote: > On Mon, 10 Jun 2024 09:56:05 +0100, > Martin Kjær Jørgensen via nginx wrote: > > > > > > Is this possible without hacking nginx sources or manipulative intermediate > > proxies? > > > > As you may see in ngx_http_header_filter_module.c such string is hardcoded. > Indeed. I'd reccomend stream njs, with it's filter phase handler, js_filter[1], if you prefer to perform such intermediary manipulation within nginx itself. There is an example of performing HTTP manipulation with js_filter here[2], albeit for injecting a custom header, but the same approach would with the 'download' callback. The Stream module itself can do TLS offloading[3], now has Virtual Servers[4], and now has direct pass to http listener feature[5] making such hacks more workable and efficient :). [1]https://nginx.org/en/docs/stream/ngx_stream_js_module.html#js_filter [2]https://github.com/nginx/njs-examples/blob/master/njs/stream/inject_header.js [3]https://nginx.org/en/docs/stream/ngx_stream_ssl_module.html [4]https://nginx.org/en/docs/stream/ngx_stream_core_module.html#server_name [5]https://nginx.org/en/docs/stream/ngx_stream_pass_module.html From jordanc.carter at outlook.com Sun Jun 16 01:45:15 2024 From: jordanc.carter at outlook.com (J Carter) Date: Sun, 16 Jun 2024 02:45:15 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: References: Message-ID: On Sun, 16 Jun 2024 04:29:51 +0300 Maxim Dounin wrote: > Hello! > > On Sat, Jun 15, 2024 at 12:02:28PM +0100, Kirill A. Korinsky wrote: > > > Greetings, > > > > Here a trivial patch which allows DNS responses with enabled AD bit > > from used resolver. > > > > Index: src/core/ngx_resolver.c > > --- src/core/ngx_resolver.c.orig > > +++ src/core/ngx_resolver.c > > @@ -1774,7 +1774,7 @@ ngx_resolver_process_response(ngx_resolver_t *r, u_cha > > (response->nar_hi << 8) + response->nar_lo); > > > > /* response to a standard query */ > > - if ((flags & 0xf870) != 0x8000 || (trunc && tcp)) { > > + if ((flags & 0xf850) != 0x8000 || (trunc && tcp)) { > > ngx_log_error(r->log_level, r->log, 0, > > "invalid %s DNS response %ui fl:%04Xi", > > tcp ? "TCP" : "UDP", ident, flags); > > > > Looks good to me, pushed with an appropriate commit log, thanks. > Sounds familiar :) https://mailman.nginx.org/pipermail/nginx-devel/2022-May/YQ3MYP4VNQYWEJS3XYLPMU4HZUKS4PYF.html From kirill at korins.ky Sun Jun 16 09:07:28 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Sun, 16 Jun 2024 10:07:28 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: References: Message-ID: On Sun, 16 Jun 2024 02:45:15 +0100, J Carter wrote: > > Sounds familiar :) > > https://mailman.nginx.org/pipermail/nginx-devel/2022-May/YQ3MYP4VNQYWEJS3XYLPMU4HZUKS4PYF.html Unfortunately, the AD bit is set by the libunbound-based resolver when it is configured to use an upstream forwarder that also supports security. My guess is that unbound uses itself as DNS client in this case and set such bit to request to the upstream. Probably it can be fixed in unbound / libunbound, but such behavior exists right now and affects many different devices... Thus, RFC 6840 suggested to set such bit when a request has one, but not required, which means that current logic of libunbound RFC complaint, and nginx is violating by rejecting such a request. -- wbr, Kirill From jordanc.carter at outlook.com Sun Jun 16 23:21:27 2024 From: jordanc.carter at outlook.com (J Carter) Date: Mon, 17 Jun 2024 00:21:27 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: References: Message-ID: Hello, On Sun, 16 Jun 2024 10:07:28 +0100 Kirill A. Korinsky wrote: > On Sun, 16 Jun 2024 02:45:15 +0100, > J Carter wrote: > > > > Sounds familiar :) > > > > https://mailman.nginx.org/pipermail/nginx-devel/2022-May/YQ3MYP4VNQYWEJS3XYLPMU4HZUKS4PYF.html > > Unfortunately, the AD bit is set by the libunbound-based resolver when it is > configured to use an upstream forwarder that also supports security. > > My guess is that unbound uses itself as DNS client in this case and set such > bit to request to the upstream. > > Probably it can be fixed in unbound / libunbound, but such behavior exists > right now and affects many different devices... > > Thus, RFC 6840 suggested to set such bit when a request has one, but not > required, which means that current logic of libunbound RFC complaint, and > nginx is violating by rejecting such a request. > Well *I* quite agree. I would also suggest that as DNS functionality in nginx is strictly limited to resolving as client in quite a simplistic fashion, and nginx does not support DNSSEC, it makes little sense to hyper-strict about the DNSSEC extension bits in general regardless of what is written in the RFCs. Perhaps it would be better if the patch linked to in my previous response was bumped and reconsidered over your patch, as that would also ignore incorrectly set CD bit in addition to ignoring AD bit, which also appears to be a common issue with certain recursive resolvers. From kirill at korins.ky Mon Jun 17 09:22:24 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Mon, 17 Jun 2024 10:22:24 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: References: Message-ID: <5880904a40e5bf25@mx2.catap.net> On Mon, 17 Jun 2024 00:21:27 +0100, J Carter wrote: > > Well *I* quite agree. > > I would also suggest that as DNS functionality in nginx is strictly > limited to resolving as client in quite a simplistic fashion, and nginx > does not support DNSSEC, it makes little sense to hyper-strict about > the DNSSEC extension bits in general regardless of what is written in > the RFCs. > > Perhaps it would be better if the patch linked to in my previous > response was bumped and reconsidered over your patch, as that would also > ignore incorrectly set CD bit in addition to ignoring AD bit, which > also appears to be a common issue with certain recursive resolvers. Well, the CD bit means that this response contains a response that fails DNSSEC, but for some reason was sent back. I've checked unbound and it returns SERVFAIL in such case, or wit no CD bit enabled if DNSSEC validation is off. Also, I've checked OpenBSD's unwind, which is libunbound-based, which has the accept bogus option for forwarder to tolerate invalid DNSSEC. Finally, I've tested a random WiFi router running dnsmasq (confirmed by fpdns) and it also returns SERVFAIL with broken DNSSEC. Do you have an example of zone and resolver that will set CD bit? -- wbr, Kirill From jordanc.carter at outlook.com Mon Jun 17 18:08:22 2024 From: jordanc.carter at outlook.com (J Carter) Date: Mon, 17 Jun 2024 19:08:22 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: <5880904a40e5bf25@mx2.catap.net> References: <5880904a40e5bf25@mx2.catap.net> Message-ID: Hello, On Mon, 17 Jun 2024 10:22:24 +0100 Kirill A. Korinsky wrote: > On Mon, 17 Jun 2024 00:21:27 +0100, > J Carter wrote: > > > > Well *I* quite agree. > > > > I would also suggest that as DNS functionality in nginx is strictly > > limited to resolving as client in quite a simplistic fashion, and nginx > > does not support DNSSEC, it makes little sense to hyper-strict about > > the DNSSEC extension bits in general regardless of what is written in > > the RFCs. > > > > Perhaps it would be better if the patch linked to in my previous > > response was bumped and reconsidered over your patch, as that would also > > ignore incorrectly set CD bit in addition to ignoring AD bit, which > > also appears to be a common issue with certain recursive resolvers. > > Well, the CD bit means that this response contains a response that fails > DNSSEC, but for some reason was sent back. > > I've checked unbound and it returns SERVFAIL in such case, or wit no CD bit > enabled if DNSSEC validation is off. > > Also, I've checked OpenBSD's unwind, which is libunbound-based, which has > the accept bogus option for forwarder to tolerate invalid DNSSEC. > > Finally, I've tested a random WiFi router running dnsmasq (confirmed by > fpdns) and it also returns SERVFAIL with broken DNSSEC. > > Do you have an example of zone and resolver that will set CD bit? > > -- > wbr, Kirill > _______________________________________________ It's caused by DNS Cache poisoning (either intentionally, or unintentionally), from a recursive resolver that caches CD bit but does not zero it if a non dns-sec query hits that cached response. I see unbound also has a ticket open for this: https://github.com/NLnetLabs/unbound/issues/649 From kirill at korins.ky Mon Jun 17 22:18:19 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Mon, 17 Jun 2024 23:18:19 +0100 Subject: Allow response with AD bit in resolver In-Reply-To: References: <5880904a40e5bf25@mx2.catap.net> Message-ID: Greetings, On Mon, 17 Jun 2024 19:08:22 +0100, J Carter wrote: > > It's caused by DNS Cache poisoning (either intentionally, or > unintentionally), from a recursive resolver that caches CD bit but > does not zero it if a non dns-sec query hits that cached response. > > I see unbound also has a ticket open for this: > https://github.com/NLnetLabs/unbound/issues/649 I just tried it on my laptop where I use local libunbound-based resolver, and I can't reproduce it: ~ $ dig +short sigfail.verteiltesysteme.net @127.0.0.1 ~ $ dig +cd +short sigfail.verteiltesysteme.net @127.0.0.1 sigfail.rsa2048-sha256.ippacket.stream. 195.201.14.36 ~ $ dig +short sigfail.verteiltesysteme.net @127.0.0.1 Thus, I've tried unbound 1.18 and 1.20 as well with the same result. But anyway, I suggest you offer a ptach because it can be quite painful for LB. -- wbr, Kirill From jordanc.carter at outlook.com Tue Jun 25 15:35:07 2024 From: jordanc.carter at outlook.com (J Carter) Date: Tue, 25 Jun 2024 16:35:07 +0100 Subject: How important is the "reuseport" flag for quic? In-Reply-To: References: Message-ID: Hello, On Sat, 15 Jun 2024 13:58:55 +0100 Dominic Preston wrote: > I'm using nginx 1.26.1 from the nginx.org ubuntu repo. > > I find when I remove the "reuseport" flag from the "listen" directive > for my quic port, a lot page assets fail to load, and the browser > ultimately falls back to http/2. > > When I re-add "reuseport", all http/3 requests succeed again. > > How crucial is "reuseport" when using quic on nginx? Is it normal for > things to break badly without it? > _______________________________________________ Very, it's required to use the reuseport parameter when using multiple workers as per the documentation here[1] so that all UDP packets of a HTTP/3/quic connection are routed to and handled by the same worker, as I understand. This is just due to limitations of how UDP (being stateless and sessionless) is handled by the kernel compared to TCP (which is session orientated). [1] https://nginx.org/en/docs/quic.html#configuration From xeioex at nginx.com Tue Jun 25 21:59:43 2024 From: xeioex at nginx.com (Dmitry Volyntsev) Date: Tue, 25 Jun 2024 14:59:43 -0700 Subject: njs-0.8.5 Message-ID: <643a9aa8-2e02-47d7-8b0e-6cfafbe3fea4@nginx.com> Hello, I'm glad to announce a new release of NGINX JavaScript module (njs). Learn more about njs: - Overview and introduction:       https://nginx.org/en/docs/njs/ - NGINX JavaScript in Your Web Server Configuration:       https://youtu.be/Jc_L6UffFOs - Extending NGINX with Custom Code:       https://youtu.be/0CVhq4AUU7M - Using node modules with njs:       https://nginx.org/en/docs/njs/node_modules.html - Writing njs code using TypeScript definition files:       https://nginx.org/en/docs/njs/typescript.html Feel free to try it and give us feedback on: - Github:       https://github.com/nginx/njs/issues Additional examples and howtos can be found here: - Github:       https://github.com/nginx/njs-examples Changes with njs 0.8.5                                       25 Jun 2024     nginx modules:     *) Change: r.variables.var, r.requestText, r.responseText,        s.variables.var, and the "data" argument of the s.on() callback        with "upload" or "download" event types will now convert bytes        invalid in UTF-8 encoding into the replacement character. When        working with binary data, use r.rawVariables.var, r.requestBuffer,        r.responseBuffer, s.rawVariables.var, and the "upstream" or        "downstream" event type for s.on() instead.     *) Feature: added timeout argument for shared dictionary methods        add(), set() and incr().     *) Bugfix: fixed checking for duplicate js_set variables.     *) Bugfix: fixed request Host header when the port is non-standard.     *) Bugfix: fixed handling of a zero-length request body in ngx.fetch()        and r.subrequest().     *) Bugfix: fixed heap-buffer-overflow in Headers.get().     *) Bugfix: fixed r.subrequest() error handling.     Core:     *) Feature: added zlib module for QuickJS engine.     *) Bugfix: fixed zlib.inflate().     *) Bugfix: fixed String.prototype.replaceAll() with zero-length        argument.     *) Bugfix: fixed retval handling after an exception in        Array.prototype.toSpliced(), Array.prototype.toReversed(),        Array.prototype.toSorted().     *) Bugfix: fixed RegExp.prototype[@@replace]() with replacements        containing "$'", "$\`" and strings with Unicode characters.     *) Bugfix: fixed a one-byte overread in decodeURI() and        decodeURIComponent().     *) Bugfix: fixed tracking of argument scope.     *) Bugfix: fixed integer overflow in Date.parse(). From lzqhwo at gmail.com Tue Jun 25 22:19:17 2024 From: lzqhwo at gmail.com (Dominic Preston) Date: Tue, 25 Jun 2024 23:19:17 +0100 Subject: How important is the "reuseport" flag for quic? In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 at 16:35, J Carter wrote: > Very, it's required to use the reuseport parameter when using multiple > workers as per the documentation here[1] so that all UDP packets of a > HTTP/3/quic connection are routed to and handled by the same worker, as > I understand. I see, thanks. It's so badly broken without the reuseport parameter that I think using multiple workers with quic should imply reuseport, or at the very least raise a warning in the logs if an attempt is made to use such a configuration. From riccardo.brunetti at host.it Wed Jun 26 14:15:11 2024 From: riccardo.brunetti at host.it (Riccardo Brunetti Host) Date: Wed, 26 Jun 2024 16:15:11 +0200 Subject: Enable http3 for a subset of domains Message-ID: Hello. I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. I placed the directives: > http3 on; > listen xx.xx.xx.xx:443 default_server quic reuseport; > quic_retry on; in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: > http3 on; > listen xx.xx.xx.xx:443 quic; > quic_retry on; In the server section and > add_header Alt-Svc 'h3=":8443"; ma=86400'; Inside the location. Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. It seems related to the type of browser. Is it an expected behaviour or I am doing something wrong with the server configuration? Nginx version: nginx/1.26.1 on ubuntu 22.04 Thanks. Riccardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Wed Jun 26 14:45:52 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Wed, 26 Jun 2024 18:45:52 +0400 Subject: Enable http3 for a subset of domains In-Reply-To: References: Message-ID: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> Hi, > On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host wrote: > > Hello. > > I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. > > I placed the directives: > >> http3 on; >> listen xx.xx.xx.xx:443 default_server quic reuseport; >> quic_retry on; > > in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: > >> http3 on; >> listen xx.xx.xx.xx:443 quic; >> quic_retry on; > > In the server section and > >> add_header Alt-Svc 'h3=":8443"; ma=86400'; > > Inside the location. > > Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. > It seems related to the type of browser. > > Is it an expected behaviour or I am doing something wrong with the server configuration? If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used. Make sure the above add_header does not affect the servers which do not support http/3. If it does, this will mislead clients by offering them to switch to unsupported http/3. > Nginx version: nginx/1.26.1 on ubuntu 22.04 > > Thanks. > Riccardo > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From riccardo.brunetti at host.it Wed Jun 26 15:21:06 2024 From: riccardo.brunetti at host.it (Riccardo Brunetti Host) Date: Wed, 26 Jun 2024 17:21:06 +0200 Subject: Enable http3 for a subset of domains In-Reply-To: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> References: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> Message-ID: Hello, thanks for the answer. > On 26 Jun 2024, at 16:45, Roman Arutyunyan wrote: > > Hi, > >> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host wrote: >> >> Hello. >> >> I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. >> >> I placed the directives: >> >>> http3 on; >>> listen xx.xx.xx.xx:443 default_server quic reuseport; >>> quic_retry on; >> >> in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: >> >>> http3 on; >>> listen xx.xx.xx.xx:443 quic; >>> quic_retry on; >> >> In the server section and >> >>> add_header Alt-Svc 'h3=":8443"; ma=86400'; >> >> Inside the location. >> >> Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. >> It seems related to the type of browser. >> >> Is it an expected behaviour or I am doing something wrong with the server configuration? > > If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used. > > Make sure the above add_header does not affect the servers which do not support http/3. I add the header above only on the virtual hosts which I want to support http/3, thus it should not interfere with the other non http/3 domains. Nevertheless, if I try with curl: 1) Site http/3 enabled: > # curl --http3 -I -v https:// > * Host t:443 was resolved. > * IPv6: (none) > * IPv4: > * WARNING: no socket in pollset, transfer may stall! > * Trying :443... > * Server certificate: > * subject: CN= > * start date: May 14 07:39:37 2024 GMT > * expire date: Aug 12 07:39:36 2024 GMT > * subjectAltName: host “" matched cert's “" > * issuer: C=US; O=Let's Encrypt; CN=R3 > * SSL certificate verify ok. > * Connected to () port 443 > * using HTTP/3 > * [HTTP/3] [0] OPENED stream for https:/// … … So it gets the correct certificate and it goes on using http/3 2) Site non http/3 enabled: > # curl --http3 -I -v https:// > * Host :443 was resolved. > * IPv6: (none) > * IPv4: > * WARNING: no socket in pollset, transfer may stall! > * Trying :443... > * SSL certificate problem: unable to get local issuer certificate > * connect to port 443 failed: SSL peer certificate or SSH remote key was not OK > * Failed to connect to port 443 after 33 ms: SSL peer certificate or SSH remote key was not OK > * Trying :443... > * Connected to () port 443 > * ALPN: curl offers h2,http/1.1 > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): > * TLSv1.3 (IN), TLS handshake, Certificate (11): > * TLSv1.3 (IN), TLS handshake, CERT verify (15): > * TLSv1.3 (IN), TLS handshake, Finished (20): > * TLSv1.3 (OUT), TLS handshake, Finished (20): > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF > * ALPN: server accepted h2 > * Server certificate: > * subject: CN= > * start date: Apr 16 08:36:25 2024 GMT > * expire date: Jul 15 08:36:24 2024 GMT > * subjectAltName: host "" matched cert's "" > * issuer: C=US; O=Let's Encrypt; CN=R3 > * SSL certificate verify ok. > * using HTTP/2 > * [HTTP/2] [1] OPENED stream for https:/// So it tries with http/3, gets a wrong certificate (the server default one), then it switches to http/2 and goes on. The first attempt with http/3 probably gives problems with some browsers? If this is the case, is there a way to avoid this or should I simply configure http/3 on all domains? > If it does, this will mislead clients by offering them to switch to unsupported http/3. > >> Nginx version: nginx/1.26.1 on ubuntu 22.04 >> >> Thanks. >> Riccardo >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx > > ---- > Roman Arutyunyan > arut at nginx.com > Riccardo > > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Wed Jun 26 15:56:20 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Wed, 26 Jun 2024 19:56:20 +0400 Subject: Enable http3 for a subset of domains In-Reply-To: References: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> Message-ID: Hi, > On 26 Jun 2024, at 7:21 PM, Riccardo Brunetti Host wrote: > > Hello, thanks for the answer. > >> On 26 Jun 2024, at 16:45, Roman Arutyunyan > wrote: >> >> Hi, >> >>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host > wrote: >>> >>> Hello. >>> >>> I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. >>> >>> I placed the directives: >>> >>>> http3 on; >>>> listen xx.xx.xx.xx:443 default_server quic reuseport; >>>> quic_retry on; >>> >>> in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: >>> >>>> http3 on; >>>> listen xx.xx.xx.xx:443 quic; >>>> quic_retry on; >>> >>> In the server section and >>> >>>> add_header Alt-Svc 'h3=":8443"; ma=86400'; >>> >>> Inside the location. >>> >>> Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. >>> It seems related to the type of browser. >>> >>> Is it an expected behaviour or I am doing something wrong with the server configuration? >> >> If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used. >> >> Make sure the above add_header does not affect the servers which do not support http/3. > > I add the header above only on the virtual hosts which I want to support http/3, thus it should not interfere with the other non http/3 domains. > Nevertheless, if I try with curl: > > 1) Site http/3 enabled: > >> # curl --http3 -I -v https:// >> * Host t:443 was resolved. >> * IPv6: (none) >> * IPv4: >> * WARNING: no socket in pollset, transfer may stall! >> * Trying :443... >> * Server certificate: >> * subject: CN= >> * start date: May 14 07:39:37 2024 GMT >> * expire date: Aug 12 07:39:36 2024 GMT >> * subjectAltName: host “" matched cert's “" >> * issuer: C=US; O=Let's Encrypt; CN=R3 >> * SSL certificate verify ok. >> * Connected to () port 443 >> * using HTTP/3 >> * [HTTP/3] [0] OPENED stream for https:/// > … > … > > So it gets the correct certificate and it goes on using http/3 > > 2) Site non http/3 enabled: > >> # curl --http3 -I -v https:// > >> * Host :443 was resolved. >> * IPv6: (none) >> * IPv4: >> * WARNING: no socket in pollset, transfer may stall! >> * Trying :443... >> * SSL certificate problem: unable to get local issuer certificate >> * connect to port 443 failed: SSL peer certificate or SSH remote key was not OK >> * Failed to connect to port 443 after 33 ms: SSL peer certificate or SSH remote key was not OK >> * Trying :443... >> * Connected to () port 443 >> * ALPN: curl offers h2,http/1.1 >> * TLSv1.2 (OUT), TLS handshake, Client hello (1): >> * TLSv1.2 (IN), TLS handshake, Server hello (2): >> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): >> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): >> * TLSv1.3 (IN), TLS handshake, Certificate (11): >> * TLSv1.3 (IN), TLS handshake, CERT verify (15): >> * TLSv1.3 (IN), TLS handshake, Finished (20): >> * TLSv1.3 (OUT), TLS handshake, Finished (20): >> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF >> * ALPN: server accepted h2 >> * Server certificate: >> * subject: CN= >> * start date: Apr 16 08:36:25 2024 GMT >> * expire date: Jul 15 08:36:24 2024 GMT >> * subjectAltName: host "" matched cert's "" >> * issuer: C=US; O=Let's Encrypt; CN=R3 >> * SSL certificate verify ok. >> * using HTTP/2 >> * [HTTP/2] [1] OPENED stream for https:/// > > > So it tries with http/3, gets a wrong certificate (the server default one), then it switches to http/2 and goes on. > The first attempt with http/3 probably gives problems with some browsers? > If this is the case, is there a way to avoid this or should I simply configure http/3 on all domains? Why would you (or client) connect to an http/3 port for a server which does not support http/3? What would be your expectation in this case? The same will happen for http/1 and http/2 as well. You can connect to an http/1 ssl port, request a missing server and receive a default server certificate. It's just there is no fallback for http/1 and client will just give up. The add_header suggests that http/3 is supported for a certain server. It should not be sent for servers which do not support http/3, and clients should not use http/3 for them. >> If it does, this will mislead clients by offering them to switch to unsupported http/3. >> >>> Nginx version: nginx/1.26.1 on ubuntu 22.04 >>> >>> Thanks. >>> Riccardo >>> _______________________________________________ >>> nginx mailing list >>> nginx at nginx.org >>> https://mailman.nginx.org/mailman/listinfo/nginx >> >> ---- >> Roman Arutyunyan >> arut at nginx.com >> > > Riccardo > >> >> >> >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From riccardo.brunetti at host.it Thu Jun 27 06:17:22 2024 From: riccardo.brunetti at host.it (Riccardo Brunetti Host) Date: Thu, 27 Jun 2024 08:17:22 +0200 Subject: Enable http3 for a subset of domains In-Reply-To: References: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> Message-ID: > On 26 Jun 2024, at 17:56, Roman Arutyunyan wrote: > > Hi, > >> On 26 Jun 2024, at 7:21 PM, Riccardo Brunetti Host wrote: >> >> Hello, thanks for the answer. >> >>> On 26 Jun 2024, at 16:45, Roman Arutyunyan > wrote: >>> >>> Hi, >>> >>>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host > wrote: >>>> >>>> Hello. >>>> >>>> I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. >>>> >>>> I placed the directives: >>>> >>>>> http3 on; >>>>> listen xx.xx.xx.xx:443 default_server quic reuseport; >>>>> quic_retry on; >>>> >>>> in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: >>>> >>>>> http3 on; >>>>> listen xx.xx.xx.xx:443 quic; >>>>> quic_retry on; >>>> >>>> In the server section and >>>> >>>>> add_header Alt-Svc 'h3=":8443"; ma=86400'; >>>> >>>> Inside the location. >>>> >>>> Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. >>>> It seems related to the type of browser. >>>> >>>> Is it an expected behaviour or I am doing something wrong with the server configuration? >>> >>> If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used. >>> >>> Make sure the above add_header does not affect the servers which do not support http/3. >> >> I add the header above only on the virtual hosts which I want to support http/3, thus it should not interfere with the other non http/3 domains. >> Nevertheless, if I try with curl: >> >> 1) Site http/3 enabled: >> >>> # curl --http3 -I -v https:// >>> * Host t:443 was resolved. >>> * IPv6: (none) >>> * IPv4: >>> * WARNING: no socket in pollset, transfer may stall! >>> * Trying :443... >>> * Server certificate: >>> * subject: CN= >>> * start date: May 14 07:39:37 2024 GMT >>> * expire date: Aug 12 07:39:36 2024 GMT >>> * subjectAltName: host “" matched cert's “" >>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>> * SSL certificate verify ok. >>> * Connected to () port 443 >>> * using HTTP/3 >>> * [HTTP/3] [0] OPENED stream for https:/// >> … >> … >> >> So it gets the correct certificate and it goes on using http/3 >> >> 2) Site non http/3 enabled: >> >>> # curl --http3 -I -v https:// >> >>> * Host :443 was resolved. >>> * IPv6: (none) >>> * IPv4: >>> * WARNING: no socket in pollset, transfer may stall! >>> * Trying :443... >>> * SSL certificate problem: unable to get local issuer certificate >>> * connect to port 443 failed: SSL peer certificate or SSH remote key was not OK >>> * Failed to connect to port 443 after 33 ms: SSL peer certificate or SSH remote key was not OK >>> * Trying :443... >>> * Connected to () port 443 >>> * ALPN: curl offers h2,http/1.1 >>> * TLSv1.2 (OUT), TLS handshake, Client hello (1): >>> * TLSv1.2 (IN), TLS handshake, Server hello (2): >>> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): >>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): >>> * TLSv1.3 (IN), TLS handshake, Certificate (11): >>> * TLSv1.3 (IN), TLS handshake, CERT verify (15): >>> * TLSv1.3 (IN), TLS handshake, Finished (20): >>> * TLSv1.3 (OUT), TLS handshake, Finished (20): >>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF >>> * ALPN: server accepted h2 >>> * Server certificate: >>> * subject: CN= >>> * start date: Apr 16 08:36:25 2024 GMT >>> * expire date: Jul 15 08:36:24 2024 GMT >>> * subjectAltName: host "" matched cert's "" >>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>> * SSL certificate verify ok. >>> * using HTTP/2 >>> * [HTTP/2] [1] OPENED stream for https:/// >> >> >> So it tries with http/3, gets a wrong certificate (the server default one), then it switches to http/2 and goes on. >> The first attempt with http/3 probably gives problems with some browsers? >> If this is the case, is there a way to avoid this or should I simply configure http/3 on all domains? > > Why would you (or client) connect to an http/3 port for a server which does not support http/3? > What would be your expectation in this case? The same will happen for http/1 and http/2 as well. > You can connect to an http/1 ssl port, request a missing server and receive a default server certificate. > It's just there is no fallback for http/1 and client will just give up. > > The add_header suggests that http/3 is supported for a certain server. > It should not be sent for servers which do not support http/3, and clients should not use http/3 for them. I agree with you, mine was an example just to show with curl what seems to happen with some browsers. It seems to me that they try http/3 even if the server doesn’t advertise the header and then stop because of the error on the certificate. I don’t know if this is something known. Anyway, I think I will bypass this by enabling http/3 on all sites. Thanks a lot for you help Riccardo > >>> If it does, this will mislead clients by offering them to switch to unsupported http/3. >>> >>>> Nginx version: nginx/1.26.1 on ubuntu 22.04 >>>> >>>> Thanks. >>>> Riccardo >>>> _______________________________________________ >>>> nginx mailing list >>>> nginx at nginx.org >>>> https://mailman.nginx.org/mailman/listinfo/nginx >>> >>> ---- >>> Roman Arutyunyan >>> arut at nginx.com >>> >> >> Riccardo >> >>> >>> >>> >>> _______________________________________________ >>> nginx mailing list >>> nginx at nginx.org >>> https://mailman.nginx.org/mailman/listinfo/nginx >> >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx > ---- > Roman Arutyunyan > arut at nginx.com > > > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From arut at nginx.com Thu Jun 27 10:26:13 2024 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 27 Jun 2024 14:26:13 +0400 Subject: Enable http3 for a subset of domains In-Reply-To: References: <67377273-D11E-4AB0-AD9A-72610FF55C8B@nginx.com> Message-ID: Hi, > On 27 Jun 2024, at 10:17 AM, Riccardo Brunetti Host wrote: > > > >> On 26 Jun 2024, at 17:56, Roman Arutyunyan > wrote: >> >> Hi, >> >>> On 26 Jun 2024, at 7:21 PM, Riccardo Brunetti Host > wrote: >>> >>> Hello, thanks for the answer. >>> >>>> On 26 Jun 2024, at 16:45, Roman Arutyunyan > wrote: >>>> >>>> Hi, >>>> >>>>> On 26 Jun 2024, at 6:15 PM, Riccardo Brunetti Host > wrote: >>>>> >>>>> Hello. >>>>> >>>>> I have a Nginx server which acts as a reverse proxy for a given number of different domains and I’m trying to enable http3 for a subset of them. >>>>> >>>>> I placed the directives: >>>>> >>>>>> http3 on; >>>>>> listen xx.xx.xx.xx:443 default_server quic reuseport; >>>>>> quic_retry on; >>>>> >>>>> in the default.conf file and then, only for those domains which I want http3 enabled I also add in the corresponding virtual host: >>>>> >>>>>> http3 on; >>>>>> listen xx.xx.xx.xx:443 quic; >>>>>> quic_retry on; >>>>> >>>>> In the server section and >>>>> >>>>>> add_header Alt-Svc 'h3=":8443"; ma=86400'; >>>>> >>>>> Inside the location. >>>>> >>>>> Now, what happens is that if I try to open the sites *with* http3 enabled, everything works as expected. If I try to open a site *without* http3 enabled, sometimes I have an SSL error because the server returns the “default virtual host” certificate. >>>>> It seems related to the type of browser. >>>>> >>>>> Is it an expected behaviour or I am doing something wrong with the server configuration? >>>> >>>> If you use http/3 to access a virtual server that does not support http/3, the default http/3 server will be used. >>>> >>>> Make sure the above add_header does not affect the servers which do not support http/3. >>> >>> I add the header above only on the virtual hosts which I want to support http/3, thus it should not interfere with the other non http/3 domains. >>> Nevertheless, if I try with curl: >>> >>> 1) Site http/3 enabled: >>> >>>> # curl --http3 -I -v https:// >>>> * Host t:443 was resolved. >>>> * IPv6: (none) >>>> * IPv4: >>>> * WARNING: no socket in pollset, transfer may stall! >>>> * Trying :443... >>>> * Server certificate: >>>> * subject: CN= >>>> * start date: May 14 07:39:37 2024 GMT >>>> * expire date: Aug 12 07:39:36 2024 GMT >>>> * subjectAltName: host “" matched cert's “" >>>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>>> * SSL certificate verify ok. >>>> * Connected to () port 443 >>>> * using HTTP/3 >>>> * [HTTP/3] [0] OPENED stream for https:/// >>> … >>> … >>> >>> So it gets the correct certificate and it goes on using http/3 >>> >>> 2) Site non http/3 enabled: >>> >>>> # curl --http3 -I -v https:// >>> >>>> * Host :443 was resolved. >>>> * IPv6: (none) >>>> * IPv4: >>>> * WARNING: no socket in pollset, transfer may stall! >>>> * Trying :443... >>>> * SSL certificate problem: unable to get local issuer certificate >>>> * connect to port 443 failed: SSL peer certificate or SSH remote key was not OK >>>> * Failed to connect to port 443 after 33 ms: SSL peer certificate or SSH remote key was not OK >>>> * Trying :443... >>>> * Connected to () port 443 >>>> * ALPN: curl offers h2,http/1.1 >>>> * TLSv1.2 (OUT), TLS handshake, Client hello (1): >>>> * TLSv1.2 (IN), TLS handshake, Server hello (2): >>>> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): >>>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): >>>> * TLSv1.3 (IN), TLS handshake, Certificate (11): >>>> * TLSv1.3 (IN), TLS handshake, CERT verify (15): >>>> * TLSv1.3 (IN), TLS handshake, Finished (20): >>>> * TLSv1.3 (OUT), TLS handshake, Finished (20): >>>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF >>>> * ALPN: server accepted h2 >>>> * Server certificate: >>>> * subject: CN= >>>> * start date: Apr 16 08:36:25 2024 GMT >>>> * expire date: Jul 15 08:36:24 2024 GMT >>>> * subjectAltName: host "" matched cert's "" >>>> * issuer: C=US; O=Let's Encrypt; CN=R3 >>>> * SSL certificate verify ok. >>>> * using HTTP/2 >>>> * [HTTP/2] [1] OPENED stream for https:/// >>> >>> >>> So it tries with http/3, gets a wrong certificate (the server default one), then it switches to http/2 and goes on. >>> The first attempt with http/3 probably gives problems with some browsers? >>> If this is the case, is there a way to avoid this or should I simply configure http/3 on all domains? >> >> Why would you (or client) connect to an http/3 port for a server which does not support http/3? >> What would be your expectation in this case? The same will happen for http/1 and http/2 as well. >> You can connect to an http/1 ssl port, request a missing server and receive a default server certificate. >> It's just there is no fallback for http/1 and client will just give up. >> >> The add_header suggests that http/3 is supported for a certain server. >> It should not be sent for servers which do not support http/3, and clients should not use http/3 for them. > > I agree with you, mine was an example just to show with curl what seems to happen with some browsers. > It seems to me that they try http/3 even if the server doesn’t advertise the header and then stop because of the error on the certificate. > I don’t know if this is something known. > Anyway, I think I will bypass this by enabling http/3 on all sites. One more thing you can do is to reject handshake for default server: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_reject_handshake > > Thanks a lot for you help > > Riccardo > >> >>>> If it does, this will mislead clients by offering them to switch to unsupported http/3. >>>> >>>>> Nginx version: nginx/1.26.1 on ubuntu 22.04 >>>>> >>>>> Thanks. >>>>> Riccardo >>>>> _______________________________________________ >>>>> nginx mailing list >>>>> nginx at nginx.org >>>>> https://mailman.nginx.org/mailman/listinfo/nginx >>>> >>>> ---- >>>> Roman Arutyunyan >>>> arut at nginx.com >>>> >>> >>> Riccardo >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> nginx mailing list >>>> nginx at nginx.org >>>> https://mailman.nginx.org/mailman/listinfo/nginx >>> >>> _______________________________________________ >>> nginx mailing list >>> nginx at nginx.org >>> https://mailman.nginx.org/mailman/listinfo/nginx >> >> ---- >> Roman Arutyunyan >> arut at nginx.com >> >> >> >> >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: