Custom Query (2296 matches)
Results (46 - 48 of 2296)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2553 | invalid | Nginx Allows any server_version starting with the number 1, HTTP/1.X | ||
| Description |
Found that if I use telnet to send non existent server protocols to my server nginx proxies it through even if its not a valid server_version. In this example I pass HTTP/1.4 telnet localhost 81 Trying ::1... Connected to localhost. Escape character is ']' GET /Hello HTTP/1.4 Host: myhostheader.com ::1 - - [27/Oct/2023:19:51:19 +0000] "GET /Hello HTTP/1.4" 404 714 "-" "-" "-" HTTP/1.1 404 Server: nginx/1.25.3 Date: Fri, 27 Oct 2023 19:51:19 GMT Content-Type: text/html;charset=utf-8 Content-Length: 714 Connection: keep-alive Content-Language: en <!doctype html>....</html> I'm not doing anything fancy to do this. I just used the nginx image and added proxy_pass # configuration file /etc/nginx/conf.d/default.conf: server {
} I would expect it to return 505 like if I enter a random other digit telnet localhost 81 Trying ::1... Connected to localhost. Escape character is ']'. GET /Hello HTTP/5.4 Host: myhostheader.comHTTP/1.1 505 HTTP Version Not Supported Server: nginx/1.25.3 Date: Fri, 27 Oct 2023 19:54:00 GMT Content-Type: text/html Content-Length: 187 Connection: close <html> <head><title>505 HTTP Version Not Supported</title></head> <body> <center><h1>505 HTTP Version Not Supported</h1></center> <hr><center>nginx/1.25.3</center> </body> </html> ::1 - - [27/Oct/2023:19:54:00 +0000] "GET /Hello HTTP/5.4" 505 187 "-" "-" "-" Connection closed by foreign host. |
|||
| #2551 | duplicate | HTTP3 Reverse Proxy does not pass on Host Header | ||
| Description |
Hi, I've encountered an issue with the HTTP/3 / QUIC setup: The minimal testsetup is the default installation with a server as from the docs + reverse proxy:
I test this setup using:
and also tracing the proxy requests using
It produces the following backend request: GET / HTTP/1.0 Host: dm-devel.hosts.dm-intern.de <-- not the originally requested header, probably the expected behaviour Connection: close user-agent: .. accept: .. Adding "proxy_set_header Host $http_host;" : GET / HTTP/1.0 <-- no Host header at all here though! Connection: close user-agent: .. accept: .. Using curl --http2 or --http1.1 it works: GET / HTTP/1.0 Host: exvhost <-- our requested Host Connection: close User-Agent: .. Accept: .. |
|||
| #2550 | duplicate | Using the 'sudo ./nginx -t' command results in the issue of the ownership of the 'proxy_temp' and other temporary folders being changed. | ||
| Description |
Hello, I am a DevOps professional from a Chinese company responsible for Nginx product operations. You can call me Peng Li. We encountered the following issue when using Nginx open-source version 1.20.2 in our production environment. On October 12th, we made modifications to the nginx_8000.conf configuration file and executed the 'sudo nginx -t' command. Following this, we noticed that the owner of all temporary files in the nginx directory had been changed to "nobody." Upon consulting the documentation, we discovered that this occurred due to the 'user' directive in the configuration file not being set to the current user. In light of the above issue, we examined the source code of the '-t' command and have some reservations about its functionality. As a tool for checking and validating Nginx configurations, wouldn't it be more reasonable for 'nginx -t' to produce an error when the user specified in the configuration file via the 'user' directive doesn't match the current owner of the temp files, rather than directly altering the user of the temp folder to "nobody"? We sincerely hope that the official developers can provide us with a detailed explanation. We deeply appreciate your assistance! |
|||
