From justdan23 at gmail.com Wed May 1 00:56:53 2024 From: justdan23 at gmail.com (Dan Swaney) Date: Tue, 30 Apr 2024 20:56:53 -0400 Subject: I need help with our NGINX set up In-Reply-To: References: <001c01da9242$e784fc40$b68ef4c0$@roze.lv> Message-ID: The clue is with the URL which failed. >From first look, you appear to be using a FAST CGI URL with PHP? Just a wild guess, but try using: ``` fastcgi_param PHP_VALUE "upload_max_filesize = 500M \n post_max_size=500M" ``` Here is a reference link mentioning it: https://serverfault.com/a/704209 On Tue, Apr 23, 2024, 4:49 AM zen zenitram wrote: > Good day! > > Here is what happen when we try to upload file more than 128 kb. Too check > if it is on server side we run the server without nginx and it can upload > larger size files. > > Thank you! > > > > On Fri, Apr 19, 2024 at 6:18 PM Reinis Rozitis via nginx > wrote: > >> > It only accepts maximum of 128 kb of data, but the client_max_body_size >> 500M;. Is there a way to locate the cause of error. >> >> Can you actually show what the "error" looks like? >> >> The default value of client_max_body_size is 1M so the 128Kb limit most >> likely comes from the backend application or server which handles the POST >> request (as an example - PHP has its own post_max_size / >> upload_max_filesize settings). >> >> >> >> p.s. while it's unlikely (as you specify the settings in particular >> location blocks) since you use wildcard includes it is always good to check >> with 'nginx -T' how the final configuration looks like. Maybe the request >> isn't handled in server/location block where you expect it .. >> >> rr >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quickfire28 at gmail.com Wed May 1 05:35:32 2024 From: quickfire28 at gmail.com (zen zenitram) Date: Wed, 1 May 2024 13:35:32 +0800 Subject: I need help with our NGINX set up In-Reply-To: References: <001c01da9242$e784fc40$b68ef4c0$@roze.lv>

Message-ID: We dont use PHP, our system use perl cgi. So the problem is in cgi? On Wed, May 1, 2024, 8:57 AM Dan Swaney wrote: > The clue is with the URL which failed. > > From first look, you appear to be using a FAST CGI URL with PHP? > > Just a wild guess, but try using: > ``` > > fastcgi_param PHP_VALUE "upload_max_filesize = 500M \n post_max_size=500M" > > ``` > > Here is a reference link mentioning it: > https://serverfault.com/a/704209 > > On Tue, Apr 23, 2024, 4:49 AM zen zenitram wrote: > >> Good day! >> >> Here is what happen when we try to upload file more than 128 kb. Too >> check if it is on server side we run the server without nginx and it can >> upload larger size files. >> >> Thank you! >> >> >> >> On Fri, Apr 19, 2024 at 6:18 PM Reinis Rozitis via nginx >> wrote: >> >>> > It only accepts maximum of 128 kb of data, but the >>> client_max_body_size 500M;. Is there a way to locate the cause of error. >>> >>> Can you actually show what the "error" looks like? >>> >>> The default value of client_max_body_size is 1M so the 128Kb limit most >>> likely comes from the backend application or server which handles the POST >>> request (as an example - PHP has its own post_max_size / >>> upload_max_filesize settings). >>> >>> >>> >>> p.s. while it's unlikely (as you specify the settings in particular >>> location blocks) since you use wildcard includes it is always good to check >>> with 'nginx -T' how the final configuration looks like. Maybe the request >>> isn't handled in server/location block where you expect it .. >>> >>> rr >>> _______________________________________________ >>> 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 >> > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srebecchi at kameleoon.com Sat May 4 17:31:43 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Sat, 4 May 2024 19:31:43 +0200 Subject: Status code 0 Message-ID: Hello What does it mean when nginx returns an http status code 0? We see that cause we monitor nginx response status code, which is used as front of our apps. The apps themselves can not return 0, only 200 or 500. So it seems issue here comes from nginx itself which can not process the connection under high peak of load, but why 0, is that expected? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From osa at freebsd.org.ru Sat May 4 17:42:39 2024 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Sat, 4 May 2024 20:42:39 +0300 Subject: Status code 0 In-Reply-To: References: Message-ID: Hi Sébastien, thanks for the report. On Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote: > > What does it mean when nginx returns an http status code 0? > > We see that cause we monitor nginx response status code, which is used as > front of our apps. The apps themselves can not return 0, only 200 or 500. > So it seems issue here comes from nginx itself which can not process the > connection under high peak of load, but why 0, is that expected? Could you please provide more details about the case: - configuration file - test cases that reproduces the issue - additional details Thank you. -- Sergey A. Osokin From mdounin at mdounin.ru Sat May 4 18:47:14 2024 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 4 May 2024 21:47:14 +0300 Subject: Status code 0 In-Reply-To: References: Message-ID: Hello! On Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote: > Hello > > What does it mean when nginx returns an http status code 0? > > We see that cause we monitor nginx response status code, which is used as > front of our apps. The apps themselves can not return 0, only 200 or 500. > So it seems issue here comes from nginx itself which can not process the > connection under high peak of load, but why 0, is that expected? Status code 0 as seen in nginx http access logs means that nginx wasn't able to generate any reasonable status code, even some generic failure like 500 (Internal Server Error), yet the request was closed. This usually happens due to some fatal issues, like unexpected conditions (which might indicate a bug somewhere), unexpected errors, or memory allocation errors if it wasn't possible to return 500. In most cases there should be additional details in the error log explaining the reasons. If there aren't any, or reasons aren't clear, it might be a good idea to dig further. -- Maxim Dounin http://mdounin.ru/ From srebecchi at kameleoon.com Mon May 6 09:33:22 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Mon, 6 May 2024 11:33:22 +0200 Subject: Status code 0 In-Reply-To: References: Message-ID: Hello! There is nothing regarding this issue in nginx logs. Now I think the issue is not with nginx itself, but in front of nginx, with Linux itself. We monitor using curl, and it seems that curl can print status code 0 when it can not establish a connection with the server. I think the Linux kernel is not configured properly to handle our connection peaks. Looking at net.core.somaxconn, we have the default of 128. More generally, I will deep dive into this and possibly other kernel settings to see if optimizing them will solve the problem. For information, on each of our servers we have an average of around 80K simultaneous TCP connections globally and around 35K in state ESTABLISHED (according to netstat/ss -nta), and more during high peaks. I saw this doc section which is a good starting point https://www.nginx.com/blog/tuning-nginx/#Tuning-Your-Linux-Configuration If you have any advice on other settings to increase, this would be very appreciated. I will keep you in touch about my investigations, to confirm at least that there is no bug on nginx side, which i am quite confident about now. Thank you very much for your help! Le sam. 4 mai 2024 à 20:47, Maxim Dounin a écrit : > Hello! > > On Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote: > > > Hello > > > > What does it mean when nginx returns an http status code 0? > > > > We see that cause we monitor nginx response status code, which is used as > > front of our apps. The apps themselves can not return 0, only 200 or 500. > > So it seems issue here comes from nginx itself which can not process the > > connection under high peak of load, but why 0, is that expected? > > Status code 0 as seen in nginx http access logs means that nginx > wasn't able to generate any reasonable status code, even some > generic failure like 500 (Internal Server Error), yet the request > was closed. > > This usually happens due to some fatal issues, like unexpected > conditions (which might indicate a bug somewhere), unexpected > errors, or memory allocation errors if it wasn't possible to > return 500. > > In most cases there should be additional details in the error log > explaining the reasons. If there aren't any, or reasons aren't > clear, it might be a good idea to dig further. > > -- > Maxim Dounin > http://mdounin.ru/ > -- > nginx mailing list > nginx at freenginx.org > https://freenginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quickfire28 at gmail.com Tue May 7 07:10:40 2024 From: quickfire28 at gmail.com (zen zenitram) Date: Tue, 7 May 2024 15:10:40 +0800 Subject: Eprints (using PERL CGI)over NGINX reverse proxy Message-ID: Good day! We have Institutional Repository that is made with the use of Eprints, It has no problem uploading file up to 1 gb as default when in local access. but when we use NGINX as the reverse proxy it only accept up to 128 kb file. Does PERL CGI affects the upload limit over NGINX? we already set the client_max_body_size to 500M yet it still accepts less than 128 kb upload. If Perl CGI affects the upload limit, How can we configure the NGINX to enable Perl CGI? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at cretaforce.gr Thu May 9 17:11:18 2024 From: chris at cretaforce.gr (Christos Chatzaras) Date: Thu, 9 May 2024 20:11:18 +0300 Subject: Bypass cache if PHPSESSID exists Message-ID: <4A983755-827E-48D7-9C42-575CC72AE7ED@cretaforce.gr> Hello, I want to bypass cache if PHPSESSID exists. I have this configuration: http { fastcgi_cache_path /tmpfs/cache levels=1:2 keys_zone=fastcgicache:10m inactive=10m max_size=1024m; fastcgi_cache_key $device_type$scheme$request_method$host$request_uri; fastcgi_cache_min_uses 1; fastcgi_cache fastcgicache; fastcgi_cache_valid 200 301 10s; fastcgi_cache_valid 302 1m; fastcgi_cache_valid 404 5m; fastcgi_cache_lock on; fastcgi_cache_lock_timeout 8000; fastcgi_pass_header Set-Cookie; fastcgi_pass_header Cookie; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_no_cache $no_cache; fastcgi_cache_bypass $no_cache; } server { location ~ [^/]\.php(/|$) { set $no_cache ""; if ($request_method = POST) { set $no_cache "1"; } if ($http_cookie ~* "_mcnc|PHPSESSID") { set $no_cache "1"; } if ($no_cache = "1") { add_header Set-Cookie "_mcnc=1; Max-Age=31536000; Path=/"; } } } When I repeatedly run curl, the content is fetched from the cache, and the Set-Cookie header always contains "PHPSESSID=604e406c1c7a6ae061bf6ce3806d5eee", leading to session leakage: curl -I https://example.com HTTP/1.1 200 OK Server: nginx Date: Thu, 09 May 2024 16:37:15 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Set-Cookie: PHPSESSID=604e406c1c7a6ae061bf6ce3806d5eee; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache X-Cache: HIT Any idea what's wrong with my configuration? Kind regards, Christos Chatzaras From kirill at korins.ky Thu May 9 18:04:12 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Thu, 09 May 2024 19:04:12 +0100 Subject: Bypass cache if PHPSESSID exists In-Reply-To: <4A983755-827E-48D7-9C42-575CC72AE7ED@cretaforce.gr> References: <4A983755-827E-48D7-9C42-575CC72AE7ED@cretaforce.gr> Message-ID: <5285e6d1a9bba6f6@mx2.catap.net> On Thu, 09 May 2024 18:11:18 +0100, Christos Chatzaras wrote: > > if ($http_cookie ~* "_mcnc|PHPSESSID") { > set $no_cache "1"; > } > Try to use map instead if. -- wbr, Kirill From l.crilly at f5.com Mon May 13 08:39:31 2024 From: l.crilly at f5.com (Liam Crilly) Date: Mon, 13 May 2024 08:39:31 +0000 Subject: nginx.org repo now on GitHub Message-ID: A small announcement to say that the sources for the nginx.org website are now maintained on GitHub: https://github.com/nginx/nginx.org Issues and PRs are open so please feel free to make suggestions and/or propose changes. Cheers, Liam. From git at frost.kiwi Tue May 14 08:03:30 2024 From: git at frost.kiwi (Wladislav Artsimovich) Date: Tue, 14 May 2024 08:03:30 +0000 Subject: How to configure HTTP CONNECT to SSH Proxy? Message-ID: <20240514080330.Horde.iIXQmemYP9Ku4HhWDwTYTVc@cloud.frost.kiwi> Dear NGINX Mailing list, I'm a user of https://github.com/proxytunnel/proxytunnel to connect to SSH over HTTPS. This requires the HTTP server to redirect the traffic to a local SSH server. Following http://dag.wiee.rs/howto/ssh-http-tunneling/ I implemented this on my server using Apache. Works great! Now I wish to transfer that config to nginx using ngx_http_proxy_connect_module. Is this possible? For simplicity, the following example shows the non encrypted configuration. The configuration is from my NixOS config. ```nix httpd = { enable = true; virtualHosts."localhost:21343" = { listen = [ { ip = "*"; port = 21343; ssl = false; } ]; extraConfig = '' LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so ProxyRequests on AllowConnect 22 # Deny all proxying by default ... Require all denied # Now allow proxying through localhost only Require all granted ''; }; ``` This results in a successful connection as tested by `proxytunnel.exe -v` (Here the connection goes through an additional local proxy `127.0.0.1:54450`, which is not relevant to the question) ``` proxytunnel.exe -v -q -p 127.0.0.1:54450 -r example.org:21343 -d 127.0.0.1:22 Tunneling to example.org:21343 (remote proxy) Communication with local proxy: -> CONNECT example.org:21343 HTTP/1.1 -> Host: example.org:21343 -> Proxy-Connection: Keep-Alive <- HTTP/1.1 200 Connection established <- Tunneling to 127.0.0.1:22 (destination) Communication with remote proxy: -> CONNECT 127.0.0.1:22 HTTP/1.1 -> Host: 127.0.0.1:22 -> Proxy-Connection: Keep-Alive <- HTTP/1.0 200 Connection Established <- Proxy-agent: Apache/2.4.59 (Unix) <- Tunnel established. SSH-2.0-OpenSSH_9.6 ``` Now I configure the same with nginx, because nginx is my main HTTP server and I wish to do this over a subdomain, instead of another random non-standard port. ```nix nginx = { enable = true; recommendedProxySettings = true; recommendedTlsSettings = true; recommendedGzipSettings = true; recommendedBrotliSettings = true; recommendedZstdSettings = true; recommendedOptimisation = true; additionalModules = [ pkgs.nginxModules.http_proxy_connect_module_v24 ]; virtualHosts = { "example.org" = { root = "/var/www/example.org"; enableACME = true; forceSSL = true; }; "ssh.example.org" = { extraConfig = '' proxy_connect; proxy_connect_allow all; # For testing set to all proxy_connect_address 127.0.0.1:22; ''; }; }; }; ``` Connecting to this results in a rejection however. ``` proxytunnel.exe -v -q -p 127.0.0.1:54450 -r ssh.example.org:80 -d 127.0.0.1:22 Tunneling to ssh.example.org:80 (remote proxy) Communication with local proxy: -> CONNECT ssh.example.org:80 HTTP/1.1 -> Host: ssh.example.org:80 -> Proxy-Connection: Keep-Alive <- HTTP/1.1 200 Connection established <- Tunneling to 127.0.0.1:22 (destination) Communication with remote proxy: -> CONNECT 127.0.0.1:22 HTTP/1.1 -> Host: 127.0.0.1:22 -> Proxy-Connection: Keep-Alive <- HTTP/1.1 405 Not Allowed <- Server: nginx <- Date: Fri, 10 May 2024 05:33:10 GMT <- Content-Type: text/html <- Content-Length: 150 <- Connection: keep-alive <- ``` What am I doing wrong? Is this possible? Best regards, Vlad From srebecchi at kameleoon.com Fri May 17 08:40:10 2024 From: srebecchi at kameleoon.com (=?UTF-8?Q?S=C3=A9bastien_Rebecchi?=) Date: Fri, 17 May 2024 10:40:10 +0200 Subject: Status code 0 In-Reply-To: References: Message-ID: Hello Just to close that conversation, it seems this was an error of our devops in charge of alerting, who was using curl in a bad way. Best regards, Sébastien Le lun. 6 mai 2024 à 11:33, Sébastien Rebecchi a écrit : > Hello! > > There is nothing regarding this issue in nginx logs. > > Now I think the issue is not with nginx itself, but in front of nginx, > with Linux itself. > We monitor using curl, and it seems that curl can print status code 0 when > it can not establish a connection with the server. > I think the Linux kernel is not configured properly to handle our > connection peaks. Looking at net.core.somaxconn, we have the default of > 128. More generally, I will deep dive into this and possibly other kernel > settings to see if optimizing them will solve the problem. For information, > on each of our servers we have an average of around 80K simultaneous TCP > connections globally and around 35K in state ESTABLISHED (according to > netstat/ss -nta), and more during high peaks. > I saw this doc section which is a good starting point > https://www.nginx.com/blog/tuning-nginx/#Tuning-Your-Linux-Configuration > If you have any advice on other settings to increase, this would be very > appreciated. > > I will keep you in touch about my investigations, to confirm at least that > there is no bug on nginx side, which i am quite confident about now. > > Thank you very much for your help! > > Le sam. 4 mai 2024 à 20:47, Maxim Dounin a écrit : > >> Hello! >> >> On Sat, May 04, 2024 at 07:31:43PM +0200, Sébastien Rebecchi wrote: >> >> > Hello >> > >> > What does it mean when nginx returns an http status code 0? >> > >> > We see that cause we monitor nginx response status code, which is used >> as >> > front of our apps. The apps themselves can not return 0, only 200 or >> 500. >> > So it seems issue here comes from nginx itself which can not process the >> > connection under high peak of load, but why 0, is that expected? >> >> Status code 0 as seen in nginx http access logs means that nginx >> wasn't able to generate any reasonable status code, even some >> generic failure like 500 (Internal Server Error), yet the request >> was closed. >> >> This usually happens due to some fatal issues, like unexpected >> conditions (which might indicate a bug somewhere), unexpected >> errors, or memory allocation errors if it wasn't possible to >> return 500. >> >> In most cases there should be additional details in the error log >> explaining the reasons. If there aren't any, or reasons aren't >> clear, it might be a good idea to dig further. >> >> -- >> Maxim Dounin >> http://mdounin.ru/ >> -- >> nginx mailing list >> nginx at freenginx.org >> https://freenginx.org/mailman/listinfo/nginx >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaushalshriyan at gmail.com Fri May 17 11:19:59 2024 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Fri, 17 May 2024 16:49:59 +0530 Subject: nginx configured as loadbalancer returning 404 not found Message-ID: Hi, I am running nginx version 1.26 on "Ubuntu 22.04.4 LTS" I have configured the nginx as load balancer and the configuration details are as follows # nginx -v nginx version: nginx/1.26.0 # server { listen 8085; #server_name 172.30.2.11; server name 210.11.1.110; location / { # Define the upstream servers for load balancing proxy_pass http://backend/; # Set HTTP headers proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /api/docs/ { proxy_pass http://backend/api/docs/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } upstream backend { server tead-local.com:80; } When i hit http://tead-local.com:80/api/docs/ I get http 200 response from the backend server whereas when I try to hit using public IP :- http://210.11.1.110:8085/api/docs/ I encounter http 404 not found. 101.0.62.200 - - [17/May/2024:16:38:24 +0530] "GET /api/docs/ HTTP/1.1" 404 153 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15 Ddg/17.5" "-" [image: image.png] Please guide me. Thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18298 bytes Desc: not available URL: From osa at freebsd.org.ru Fri May 17 14:09:03 2024 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Fri, 17 May 2024 17:09:03 +0300 Subject: nginx configured as loadbalancer returning 404 not found In-Reply-To: References: Message-ID: Hi Kaushal, On Fri, May 17, 2024 at 04:49:59PM +0530, Kaushal Shriyan wrote: > > I am running nginx version 1.26 on "Ubuntu 22.04.4 LTS" I have configured > the nginx as load balancer and the configuration details are as follows > > # nginx -v > nginx version: nginx/1.26.0 > # > > server { [...] > > location / { > # Define the upstream servers for load balancing > proxy_pass http://backend/; Could you please explain a reason why did you decide to use `/' after the backend's name in the proxy_pass directive. > # Set HTTP headers > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > } > > location /api/docs/ { > proxy_pass http://backend/api/docs/; It seems like '/api/docs/' can be safely removed, so I'd recommend to read the documentation for the proxy_pass directive, [1] If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI: location /some/path/ { proxy_pass http://127.0.0.1; } [...] > When i hit http://tead-local.com:80/api/docs/ I get http 200 response from > the backend server whereas when I try to hit using public IP :- > http://210.11.1.110:8085/api/docs/ I encounter http 404 not found. > > 101.0.62.200 - - [17/May/2024:16:38:24 +0530] "GET /api/docs/ HTTP/1.1" 404 > 153 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15 > Ddg/17.5" "-" To see the whole picture of processing a request by nginx, I'd also recommend to enable a debugging log, [2]. Hope that helps. References ---------- 1. https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass 2. https://nginx.org/en/docs/debugging_log.html -- Sergey A. Osokin From francis at daoine.org Sat May 18 00:11:21 2024 From: francis at daoine.org (francis at daoine.org) Date: Fri, 17 May 2024 17:11:21 -0700 Subject: Returned mail: Data format error Message-ID: (�9�M��{��]P�|��%�&��i# �� !GE�ate�U��l��p<�G��.o�� g��_X��P�R��eV��4�J$�y'��K�)�O5��&�!w��bHN��a��x,~��P��3�s4��b?�i��UFG��^;��W ��71��Ow}��Rt�e��k}�9W��1��)�s`R��r�A�d��?�a��7b��r��{J��4(�)�B)� ��KS`9�?��c��m��N^��k9��B�jJDc��'��]��Gr�**��]��{��#��,,v%�2�wR�j"`cXb�|�6�X3��P��9�{�C��!�v��c!FD�,2��yuR �RV%�g26��X��Y{��a|�&�H�<�k��g6i2�.e��[��F�A��R��"��{X�8��_B��!��X�-�9��hd��x��U){,x��1d�w�Vx�,�K�2D��U��6��$�i�� W|��*��V�l%�[�� SD��E��'��,��9t~�Uz-~:*�OR��k��<,�K��e�Y��q8�Apa��y'��'�i� `��p�|��F��;�x�:|��Y��zo�E��E�3��q��$��j��n`�L��E�3��n�qn0># 5�$Bo��*mw��;��b��jP ��-��F�Lz� �OL�4��`v��-4O�T��)��Y�!�L�:�{��f��Z��"#��I��nG��7q��DCFX0u�n�`L �[B��W{�{��<��OHV��N��r�BOd�;��,S�D�#��a��"��rG�c�d��x}3��g��~�m��xA�JPj�� \_�.#��"*78��I� ��Z]��SzL��dE5S�d��X�I��}��X��D�)�ob{�G��lJj��X�xJ��e**wz��5S*��5v9�y��W��Ux��E$U��D�E5��n�dx\�Jc3|-�%�O8k�F��y��#�N��O��a��?�1��w��^��N��1y xp��A 9��*1�Z�Fv��TrxGR��-$��f��W��?CU�G&%� ��C��Er. ��C�Ql��x�sg��E�g6�s�4��8F��V�b.�RB��'�K��4�~8��o)&�h��Ww��B��-��%�Y�y�D)F$d��a��T`��E�D��Y��<��H6j`!%��tW�Cd�� -------------- next part -------------- A non-text attachment was scrubbed... Name: document.zip Type: application/octet-stream Size: 30170 bytes Desc: not available URL: From kaushalshriyan at gmail.com Fri May 17 19:41:55 2024 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Sat, 18 May 2024 01:11:55 +0530 Subject: nginx configured as loadbalancer returning 404 not found In-Reply-To: References: Message-ID: On Fri, May 17, 2024 at 7:39 PM Sergey A. Osokin wrote: > Hi Kaushal, > > On Fri, May 17, 2024 at 04:49:59PM +0530, Kaushal Shriyan wrote: > > > > I am running nginx version 1.26 on "Ubuntu 22.04.4 LTS" I have configured > > the nginx as load balancer and the configuration details are as follows > > > > # nginx -v > > nginx version: nginx/1.26.0 > > # > > > > server { > [...] > > > > location / { > > # Define the upstream servers for load balancing > > proxy_pass http://backend/; > > Could you please explain a reason why did you decide to use `/' after > the backend's name in the proxy_pass directive. > > > # Set HTTP headers > > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_set_header X-Forwarded-Proto $scheme; > > } > > > > location /api/docs/ { > > proxy_pass http://backend/api/docs/; > > It seems like '/api/docs/' can be safely removed, so > I'd recommend to read the documentation for the proxy_pass directive, [1] > > > > If proxy_pass is specified without a URI, the request URI is passed to the > server in the same form as sent by a client when the original request is > processed, or the full normalized request URI is passed when processing > the changed URI: > > location /some/path/ { > proxy_pass http://127.0.0.1; > } > > > > [...] > > > When i hit http://tead-local.com:80/api/docs/ I get http 200 response > from > > the backend server whereas when I try to hit using public IP :- > > http://210.11.1.110:8085/api/docs/ I encounter http 404 not found. > > > > 101.0.62.200 - - [17/May/2024:16:38:24 +0530] "GET /api/docs/ HTTP/1.1" > 404 > > 153 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15 > > Ddg/17.5" "-" > > To see the whole picture of processing a request by nginx, I'd > also recommend to enable a debugging log, [2]. > > Hope that helps. > > References > ---------- > 1. https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass > 2. https://nginx.org/en/docs/debugging_log.html > > -- > Sergey A. Osokin > Thanks Sergey for the detailed explanation. I have modified the /etc/nginx/conf.d/loadbalancer.conf file (nginx server running in loadbalancer mode). The upstream backend -> tead-local.com:80 is hosted on docker based container running nginx service (version :- 1.21.6) ##############################loadbalancer.conf############################################### server { listen 80; server_name testbe.mydomain.com; error_log /var/log/nginx/nginxdebug.log debug; location / { # Define the upstream servers for load balancing proxy_pass http://backend; # Set HTTP headers proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; error_log /var/log/nginx/nginxlocationdebug.log debug; } } upstream backend { server tead-local.com:80; } ########################################################################################## [image: image.png] # ll total 12 drwxr-xr-x 2 root adm 93 May 18 01:05 ./ drwxrwxr-x 15 root syslog 4096 May 16 16:33 ../ -rw-r--r-- 1 root root 621 May 18 01:05 access.log -rw-r--r-- 1 root root 594 May 18 01:05 error.log -rw-r--r-- 1 root root 0 May 18 01:05 nginxdebug.log -rw-r--r-- 1 root root 0 May 18 01:05 nginxlocationdebug.log # root at lb-01:/var/log/nginx# cat error.log 2024/05/18 01:05:15 [notice] 539625#539625: using the "epoll" event method 2024/05/18 01:05:15 [notice] 539625#539625: nginx/1.26.0 2024/05/18 01:05:15 [notice] 539625#539625: built by gcc 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 2024/05/18 01:05:15 [notice] 539625#539625: OS: Linux 5.15.0-105-generic 2024/05/18 01:05:15 [notice] 539625#539625: getrlimit(RLIMIT_NOFILE): 1024:524288 2024/05/18 01:05:15 [notice] 539626#539626: start worker processes 2024/05/18 01:05:15 [notice] 539626#539626: start worker process 539627 2024/05/18 01:05:15 [notice] 539626#539626: start worker process 539628 root at lb-01:/var/log/nginx# ll # cat access.log 101.0.62.200 - - [18/May/2024:01:05:19 +0530] "GET /api/docs HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" "-" 101.0.62.200 - - [18/May/2024:01:05:20 +0530] "GET /api/docs HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" "-" 101.0.62.200 - - [18/May/2024:01:05:21 +0530] "GET /api/docs HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" "-" # # cat nginxdebug.log 2024/05/18 01:06:19 [info] 539627#539627: *2 client timed out (110: Connection timed out) while waiting for request, client: 101.0.62.200, server: 0.0.0.0:80 2024/05/18 01:08:01 [info] 539628#539628: *7 client timed out (110: Connection timed out) while waiting for request, client: 101.0.62.200, server: 0.0.0.0:80 # # nginx -v nginx version: nginx/1.26.0 # Am I missing anything? Please guide me. Thanks in advance. Best Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 17421 bytes Desc: not available URL: From venefax at gmail.com Sun May 19 20:47:02 2024 From: venefax at gmail.com (Saint Michael) Date: Sun, 19 May 2024 16:47:02 -0400 Subject: Twitter incompatibility In-Reply-To: <20240429122728.xr2gkxmwmfrcqjbx@N00W24XTQX> References:

<20240429122728.xr2gkxmwmfrcqjbx@N00W24XTQX> Message-ID: I need some help with a Nginx,. Twitter problem please open a twitter client x.com and post this link https://patrician.org/22a51cfb-7d5b-4a97-a687-a10cd1946766/ and then open a new client and post https://xlong.org/p/a3622727-4df1-46f3-aee8-ee0a43194906/ in the first case, it's an Apache server, and X pulls the twitter card just fine in the second, it fails, it posts the link as is, very ugly, no image both link works, but only Apache allows twitter to work as intended, pulling image called "twitter:card" I tried with both on and off versions of underscores_in_headers on; ignore_invalid_headers on; my configuration is: http { client_body_buffer_size 150M; client_max_body_size 150M; include mime.types; default_type 'text/html; charset=UTF-8'; #application/octet-stream; types { # Common video formats video/ogg ogv; video/x-matroska mkv; application/xml xml; } ssl_buffer_size 4k; ssl_session_cache shared:SSL:1m; # holds approx 4000 sessions ssl_session_timeout 1h; # 1 hour during which sessions can be re-used. ssl_session_tickets off; #ssl_protocols TLSv1.2 TLSv1.3; sendfile on; tcp_nopush on; tcp_nodelay on; gzip on; gzip_vary on; gzip_min_length 10240; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml; gzip_disable "MSIE [1-6]\."; keepalive_timeout 65; types_hash_max_size 2048; proxy_headers_hash_max_size 1024; proxy_headers_hash_bucket_size 128; server_tokens off; log_format custom '"$host" $remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; error_log /var/log/nginx/error.log error; access_log /var/log/nginx/access.log custom; underscores_in_headers on; ignore_invalid_headers on; From jordanc.carter at outlook.com Sun May 19 22:27:53 2024 From: jordanc.carter at outlook.com (J Carter) Date: Sun, 19 May 2024 23:27:53 +0100 Subject: Twitter incompatibility In-Reply-To: References:

<20240429122728.xr2gkxmwmfrcqjbx@N00W24XTQX> Message-ID: Hello, On Sun, 19 May 2024 16:47:02 -0400 Saint Michael wrote: > I need some help with a Nginx,. Twitter problem > please open a twitter client x.com > and post this link > https://patrician.org/22a51cfb-7d5b-4a97-a687-a10cd1946766/ > and then open a new client and post > https://xlong.org/p/a3622727-4df1-46f3-aee8-ee0a43194906/ > > in the first case, it's an Apache server, and X pulls the twitter card just fine > in the second, it fails, it posts the link as is, very ugly, no image > both link works, but only Apache allows twitter to work as intended, > pulling image called "twitter:card" When accessing the new page's twitter:image target image directly I see the following: curl http://ssnode1.minixel.com/p/papel-literario-2.jpg -i HTTP/1.1 200 OK Server: openresty Date: Sun, 19 May 2024 22:07:18 GMT Content-Type: image/jpeg Content-Length: 93273 Last-Modified: Mon, 29 Apr 2024 23:52:26 GMT Connection: keep-alive ETag: "663032ba-16c59" Cache-Control: no-cache,: no-store, must-revalidate Access-Control-Allow-Origin: * Pragma: no-cache Accept-Ranges: bytes ... A) Cache Control header appears to be malformed, notice it's contents are in it's own header, and Cache-Control is empty. B) Twitter actually caches and serves preview image, they do not link directly to image on your site - perhaps just try removing Cache-Control header and Pragma: no-cache altogether. Old version has neither of these issues (see below). curl -i http://patrician.org/papel-literario-2.jpg -L HTTP/1.1 301 Moved Permanently Date: Sun, 19 May 2024 22:11:29 GMT Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k Location: https://patrician.org/papel-literario-2.jpg Content-Length: 251 Content-Type: text/html; charset=iso-8859-1 HTTP/1.1 200 OK Date: Sun, 19 May 2024 22:11:29 GMT Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k Last-Modified: Sun, 19 May 2024 16:15:57 GMT ETag: "16c59-618d0e65ae1e3" Accept-Ranges: bytes Content-Length: 93273 Content-Type: image/jpeg ... Old version does also do http->https redirect, although I wouldn't think lack of that would cause an issue. Just as an aside you can use twitter card validator here[1] to validate cards - xlong.org domain's version of page currently shows "internal server error" for me, old domain passes checks. [1] https://cards-dev.twitter.com/validator From venefax at gmail.com Mon May 20 04:25:06 2024 From: venefax at gmail.com (Saint Michael) Date: Mon, 20 May 2024 00:25:06 -0400 Subject: Twitter incompatibility In-Reply-To: References:

<20240429122728.xr2gkxmwmfrcqjbx@N00W24XTQX> Message-ID: Fixed, many thanks. I had asked ChatGPT 4o and it could not help. On Sun, May 19, 2024 at 6:28 PM J Carter wrote: > > Hello, > > On Sun, 19 May 2024 16:47:02 -0400 > Saint Michael wrote: > > > I need some help with a Nginx,. Twitter problem > > please open a twitter client x.com > > and post this link > > https://patrician.org/22a51cfb-7d5b-4a97-a687-a10cd1946766/ > > and then open a new client and post > > https://xlong.org/p/a3622727-4df1-46f3-aee8-ee0a43194906/ > > > > in the first case, it's an Apache server, and X pulls the twitter card just fine > > in the second, it fails, it posts the link as is, very ugly, no image > > both link works, but only Apache allows twitter to work as intended, > > pulling image called "twitter:card" > > When accessing the new page's twitter:image target image directly I see > the following: > > curl http://ssnode1.minixel.com/p/papel-literario-2.jpg -i > HTTP/1.1 200 OK > Server: openresty > Date: Sun, 19 May 2024 22:07:18 GMT > Content-Type: image/jpeg > Content-Length: 93273 > Last-Modified: Mon, 29 Apr 2024 23:52:26 GMT > Connection: keep-alive > ETag: "663032ba-16c59" > Cache-Control: > no-cache,: no-store, must-revalidate > Access-Control-Allow-Origin: * > Pragma: no-cache > Accept-Ranges: bytes > ... > > A) Cache Control header appears to be malformed, notice it's contents > are in it's own header, and Cache-Control is empty. > > B) Twitter actually caches and serves preview image, they do not link > directly to image on your site - perhaps just try removing > Cache-Control header and Pragma: no-cache altogether. > > Old version has neither of these issues (see below). > > curl -i http://patrician.org/papel-literario-2.jpg -L > HTTP/1.1 301 Moved Permanently > Date: Sun, 19 May 2024 22:11:29 GMT > Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k > Location: https://patrician.org/papel-literario-2.jpg > Content-Length: 251 > Content-Type: text/html; charset=iso-8859-1 > > HTTP/1.1 200 OK > Date: Sun, 19 May 2024 22:11:29 GMT > Server: Apache/2.4.37 (CentOS Stream) OpenSSL/1.1.1k > Last-Modified: Sun, 19 May 2024 16:15:57 GMT > ETag: "16c59-618d0e65ae1e3" > Accept-Ranges: bytes > Content-Length: 93273 > Content-Type: image/jpeg > ... > > Old version does also do http->https redirect, although I wouldn't > think lack of that would cause an issue. > > Just as an aside you can use twitter card validator here[1] to validate > cards - xlong.org domain's version of page currently shows > "internal server error" for me, old domain passes checks. > > [1] https://cards-dev.twitter.com/validator > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From noloader at gmail.com Tue May 21 12:37:09 2024 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 May 2024 08:37:09 -0400 Subject: SVN front-end using Nginx? Message-ID: Hi Everyone, I'd like to use SVN, and Nginx as the web server for it. From what I've found, it looks like Apache is required due to mod_dav_svn (and the combo is Apache with Nginx proxy). I also came across svnserve, but I am not familiar with it. Is anyone aware of a way to use a pure Nginx environment for SVN? Thanks in advance. From kirill at korins.ky Fri May 24 09:58:15 2024 From: kirill at korins.ky (Kirill A. Korinsky) Date: Fri, 24 May 2024 10:58:15 +0100 Subject: [PATCH] Add $upstream_cache_key Message-ID: Greetings, Here is a patch that exposes the constructed cache key as $upstream_cache_key variable. Sometimes it's quite useful when debugging complicated setups and fighting some typos. I've attached two patches: 1. from me to add that variable 2. from Maxim Dounin to update docs -- wbr, Kirill -------------- next part -------------- A non-text attachment was scrubbed... Name: upstream_cache_key.diff Type: application/octet-stream Size: 2340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: docs.diff Type: application/octet-stream Size: 4808 bytes Desc: not available URL: From varigergo07 at gmail.com Sun May 26 08:17:06 2024 From: varigergo07 at gmail.com (=?UTF-8?B?R2VyZ8WRIFbDoXJp?=) Date: Sun, 26 May 2024 08:17:06 +0000 Subject: =?US-ASCII?Q?NGINX_multiple_authentication_methods_=28one_o?= =?US-ASCII?Q?r_the_other=29_AND_an_IP_check_seems_impossible?= Message-ID: <7F865C57-4D7C-47EA-B958-0182ADD29211@gmail.com> ``` location / { proxy_pass $forward_auth_target; allow xxxxx/24; deny all; satisfy any; # This gets satisfied by the IP check, and auth is completely bypassed auth_basic "xxxx"; auth_basic_user_file "/etc/nginx/basic_auth/$forward_auth_bypass"; auth_request /outpost.goauthentik.io/auth/nginx; error_page 401 = @goauthentik_proxy_signin; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; proxy_set_header X-authentik-username $authentik_username; auth_request_set $authentik_username $upstream_http_x_authentik_username; auth_request_set $authentik_groups $upstream_http_x_authentik_groups; proxy_set_header X-authentik-groups $authentik_groups; auth_request_set $authentik_email $upstream_http_x_authentik_email; proxy_set_header X-authentik-email $authentik_email; auth_request_set $authentik_name $upstream_http_x_authentik_name; proxy_set_header X-authentik-name $authentik_name; auth_request_set $authentik_uid $upstream_http_x_authentik_uid; proxy_set_header X-authentik-uid $authentik_uid; auth_request_set $authentik_uid $upstream_http_x_authentik_uid; proxy_set_header X-authentik-uid $authentik_uid; auth_request_set $authentik_auth $upstream_http_authorization; proxy_set_header Authorization $authentik_auth; } location /outpost.goauthentik.io { proxy_pass http://xxxx/outpost.goauthentik.io; proxy_set_header Host $host; proxy_set_header X-Original-URL $scheme://$http_host$request_uri; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie $upstream_http_set_cookie; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_ssl_verify off; } location @goauthentik_proxy_signin { internal; add_header Set-Cookie $auth_cookie; return 302 /outpost.goauthentik.io/start?rd=$request_uri; } ``` The goal is to bypass SSO if a correct HTTP Basic Auth header is present while making sure connections are only from said IPs. When I disable the IP check it works flawlessly. How could I separate these requirements? So (SSO or Basic Auth) and Correct IP -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordanc.carter at outlook.com Mon May 27 06:48:40 2024 From: jordanc.carter at outlook.com (J Carter) Date: Mon, 27 May 2024 07:48:40 +0100 Subject: NGINX multiple authentication methods (one or the other) AND an IP check seems impossible In-Reply-To: <7F865C57-4D7C-47EA-B958-0182ADD29211@gmail.com> References: <7F865C57-4D7C-47EA-B958-0182ADD29211@gmail.com> Message-ID: Hello, [...] > ``` > The goal is to bypass SSO if a correct HTTP Basic Auth header is present while making sure connections are only from said IPs. > > When I disable the IP check it works flawlessly. How could I separate these requirements? > > So (SSO or Basic Auth) and Correct IP Just use the geo module and "if" to reject unwanted IPs. "If" is evaluated prior to access & post_access phases, where auth_basic and co are evaluated. geo $allowed_ip { xxx.xxx.xxx.xxx/24 1; default 0; } ... location / { if ($allowed_ip = 0) { return 403; } ....rest of config without allow/deny. } From varigergo07 at gmail.com Mon May 27 11:11:01 2024 From: varigergo07 at gmail.com (=?UTF-8?B?R2VyZ8WRIFbDoXJp?=) Date: Mon, 27 May 2024 11:11:01 +0000 Subject: =?US-ASCII?Q?Re=3A_NGINX_multiple_authentication_methods_=28one?= =?US-ASCII?Q?_or_the_other=29_AND_an_IP_check_seems_impossible?= In-Reply-To: References: <7F865C57-4D7C-47EA-B958-0182ADD29211@gmail.com> Message-ID: That works wonderfully, thank you! On May 27, 2024 6:48:40 AM UTC, J Carter wrote: >Hello, > >[...] > >> ``` >> The goal is to bypass SSO if a correct HTTP Basic Auth header is present while making sure connections are only from said IPs. >> >> When I disable the IP check it works flawlessly. How could I separate these requirements? >> >> So (SSO or Basic Auth) and Correct IP > >Just use the geo module and "if" to reject unwanted IPs. > >"If" is evaluated prior to access & post_access phases, where auth_basic >and co are evaluated. > >geo $allowed_ip { > xxx.xxx.xxx.xxx/24 1; > default 0; >} > >... > >location / { > if ($allowed_ip = 0) { > return 403; > } > > ....rest of config without allow/deny. >} >_______________________________________________ >nginx mailing list >nginx at nginx.org >https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From pluknet at nginx.com Wed May 29 15:10:06 2024 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:10:06 +0400 Subject: nginx-1.27.0 Message-ID: <3B51E46D-264F-47FC-B433-E23B4068811A@nginx.com> Changes with nginx 1.27.0 29 May 2024 *) Security: when using HTTP/3, processing of a specially crafted QUIC session might cause a worker process crash, worker process memory disclosure on systems with MTU larger than 4096 bytes, or might have potential other impact (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). Thanks to Nils Bars of CISPA. *) Feature: variables support in the "proxy_limit_rate", "fastcgi_limit_rate", "scgi_limit_rate", and "uwsgi_limit_rate" directives. *) Bugfix: reduced memory consumption for long-lived requests if "gzip", "gunzip", "ssi", "sub_filter", or "grpc_pass" directives are used. *) Bugfix: nginx could not be built by gcc 14 if the --with-atomic option was used. Thanks to Edgar Bonet. *) Bugfixes in HTTP/3. -- Sergey Kandaurov From pluknet at nginx.com Wed May 29 15:10:11 2024 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:10:11 +0400 Subject: nginx-1.26.1 Message-ID: <8488B55A-F60C-454D-94D1-9030E63065A3@nginx.com> Changes with nginx 1.26.1 29 May 2024 *) Security: when using HTTP/3, processing of a specially crafted QUIC session might cause a worker process crash, worker process memory disclosure on systems with MTU larger than 4096 bytes, or might have potential other impact (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). Thanks to Nils Bars of CISPA. *) Bugfix: reduced memory consumption for long-lived requests if "gzip", "gunzip", "ssi", "sub_filter", or "grpc_pass" directives are used. *) Bugfix: nginx could not be built by gcc 14 if the --with-atomic option was used. Thanks to Edgar Bonet. *) Bugfix: in HTTP/3. -- Sergey Kandaurov From pluknet at nginx.com Wed May 29 15:10:16 2024 From: pluknet at nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:10:16 +0400 Subject: nginx security advisory (CVE-2024-31079, CVE-2024-32760, CVE-2024-34161, CVE-2024-35200) Message-ID: <7FE877BE-68A2-434B-B5C5-AC3EFE552DF5@nginx.com> Hello! Four security issues were identified in nginx HTTP/3 implementation, which might allow an attacker that uses a specially crafted QUIC session to cause a worker process crash (CVE-2024-31079, CVE-2024-32760, CVE-2024-35200), worker process memory disclosure on systems with MTU larger than 4096 bytes (CVE-2024-34161), or might have potential other impact (CVE-2024-31079, CVE-2024-32760). The issues affect nginx compiled with the experimental ngx_http_v3_module (not compiled by default) if the "quic" option of the "listen" directive is used in a configuration file. The issues affect nginx 1.25.0-1.25.5, 1.26.0. The issues are fixed in nginx 1.27.0, 1.26.1. Thanks to Nils Bars of CISPA. -- Sergey Kandaurov From daniel at jagszent.de Wed May 29 15:52:36 2024 From: daniel at jagszent.de (Daniel Jagszent) Date: Wed, 29 May 2024 17:52:36 +0200 Subject: nginx-1.27.0 - shasum does not match with expected shasum from pkg-oss Message-ID: <543920c2-fe98-8f2e-53f7-512e75acb946@jagszent.de> Hello, the SHA512 of https://nginx.org/download/nginx-1.27.0.tar.gz (downloaded 2024-05-29 15:42:02 UTC) is 251bfe65c717a8027ef05caae2ab2ea73b9b544577f539a1d419fe6adf0bcc846b73b58f54ea3f102df79aaf340e4fa56793ddadea3cd61bcbbe2364ef94bacb This does not match with the shasum expected here https://hg.nginx.org/pkg-oss/file/tip/contrib/src/nginx/SHA512SUMS#l57 From iippolitov at nginx.com Wed May 29 16:22:18 2024 From: iippolitov at nginx.com (Igor Ippolitov) Date: Wed, 29 May 2024 17:22:18 +0100 Subject: nginx-1.27.0 - shasum does not match with expected shasum from pkg-oss In-Reply-To: <543920c2-fe98-8f2e-53f7-512e75acb946@jagszent.de> References: <543920c2-fe98-8f2e-53f7-512e75acb946@jagszent.de> Message-ID: On 29/05/2024 16:52, Daniel Jagszent wrote: > Hello, > > the SHA512 of https://nginx.org/download/nginx-1.27.0.tar.gz (downloaded > 2024-05-29 15:42:02 UTC) is > 251bfe65c717a8027ef05caae2ab2ea73b9b544577f539a1d419fe6adf0bcc846b73b58f54ea3f102df79aaf340e4fa56793ddadea3cd61bcbbe2364ef94bacb > > This does not match with the shasum expected here > https://hg.nginx.org/pkg-oss/file/tip/contrib/src/nginx/SHA512SUMS#l57 > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx Daniel, Thank you for spotting this. Indeed, due to last minute change into CHANGES wording the checksum of published archives differs from what pkg-oss expects. There are no changes into code though. We are working on publishing new packages and updated pkg-oss repository with corrected checksums. I will update you later when packages and pkg-oss are published. Kind regards, Igor From iippolitov at nginx.com Wed May 29 21:28:30 2024 From: iippolitov at nginx.com (Igor Ippolitov) Date: Wed, 29 May 2024 22:28:30 +0100 Subject: nginx-1.27.0 - shasum does not match with expected shasum from pkg-oss In-Reply-To: References: <543920c2-fe98-8f2e-53f7-512e75acb946@jagszent.de> Message-ID: <619c1a25-dfa8-421f-a68f-7009fed1c7b3@nginx.com> On 29/05/2024 17:22, Igor Ippolitov wrote: > On 29/05/2024 16:52, Daniel Jagszent wrote: >> Hello, >> >> the SHA512 of https://nginx.org/download/nginx-1.27.0.tar.gz (downloaded >> 2024-05-29 15:42:02 UTC) is >> 251bfe65c717a8027ef05caae2ab2ea73b9b544577f539a1d419fe6adf0bcc846b73b58f54ea3f102df79aaf340e4fa56793ddadea3cd61bcbbe2364ef94bacb >> >> >> This does not match with the shasum expected here >> https://hg.nginx.org/pkg-oss/file/tip/contrib/src/nginx/SHA512SUMS#l57 >> _______________________________________________ > Daniel, > > Thank you for spotting this. > > Indeed, due to last minute change into CHANGES wording the checksum of > published archives differs from what pkg-oss expects. > There are no changes into code though. > We are working on publishing new packages and updated pkg-oss > repository with corrected checksums. > > I will update you later when packages and pkg-oss are published. > > Kind regards, > Igor > _______________________________________________ > Daniel, pkg-oss and packages themselves were published and should match sources precisely. Kind regards, Igor.