Opened 2 years ago
Last modified 2 years ago
#2395 new enhancement
`proxy_pass https://example` if `upstream example { server example.com; }` is defined, uses port `80`, not `443` per `https`
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.23.x |
| Keywords: | Cc: | ||
| uname -a: | Linux example.com 3.10.0-1160.59.1.el7.x86_64 #1 SMP Wed Feb 16 12:17:35 UTC 2022 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.23.1
built by gcc 10.2.1 20210110 (Debian 10.2.1-6) built with OpenSSL 1.1.1n 15 Mar 2022 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -ffile-prefix-map=/data/builder/debuild/nginx-1.23.1/debian/debuild-base/nginx-1.23.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' |
||
Description
Hi all,
I would think that in absence of a port number specified with the value of the server directive in an upstream block, when the upstream is used in a URL, like with the proxy_pass directive, then the presence of https as URL scheme should absolutely imply the port associated with HTTPS -- 443. Instead, Nginx attempts to connect to the upstream on port 80 specifically.
Is this an issue that should be addressed? Shouldn't Nginx use port 443 when the upstream is used in a URL with the https scheme, like in the value of proxy_pass et al?
The current mitigation, in my humble opinion, impairs readability and is unnecessarily confusing, not to mention may surprise the reader:
upstream example { server example.com:443; } # Reader: Isn't HTTPS 443 by default? Why is `:443` necessary here? (Nginx: because by default it's 80, my dear chap)
proxy_pass https://example;
Note:
See TracTickets
for help on using tickets.
The
upstreamblock is a separate entity, and it does not know anything about protocols it is going to be used with. It can be used with http, https, fastcgi, uwsgi, memcached, and so on (and, further, the same upstream block can be used with multiple protocols at the same time). Instead, it defines a network addresses to connect to: that is, an IP address and a port.If the port is not specified, it defaults to 80, since this is the most common port (and the upstream block knows nothing about protocols it is going to be used, see above). In practice, you probably want to always specify the port to use, even if it happens to be 80: in particular, to make sure that a configuration trying to connect to an upstream via https isn't misread as using port 443.
Summing the above, changing the default to 443 if an upstream is used in
proxy_pass https://...looks way to complicated for both the code (nginx will have to postpone port assignment somehow till the protocol is known, and will have to check if the same upstream isn't used with different protocols) and users (it would be required to read the whole configuration to understand the network addresses being used), and not something we are willing to do. Removing the default to make sure the port is always explicitly specified might be an option though.