Open doggy8088 opened 1 year ago
When you say the syntax is "wrong", how does the routing behaviour break/change? Can you give an example of requests that are being routed incorrectly as a result of this?
Here is my use case:
I tested. When using location /
, only the /
been routed in NGINX 1.23.2
. The /style.css
won't route, it will get 404 not found.
Here is my server config, there is only one location
directive.
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mysite;
root /usr/share/nginx/html/public;
# SSL
ssl_certificate /etc/nginx/ssl/mysite.pem;
ssl_certificate_key /etc/nginx/ssl/mysite-key.pem;
# security
include nginxconfig.io/security.conf;
# logging
access_log /var/log/nginx/access.log combined buffer=512k flush=1m;
error_log /var/log/nginx/error.log error;
# reverse proxy
location ^~ / {
resolver 127.0.0.11;
set $upstream_host my-app;
proxy_pass http://$upstream_host:50050;
proxy_set_header Host $host;
include nginxconfig.io/proxy.conf;
}
# additional config
include nginxconfig.io/general.conf;
}
Ah I see, because nginxconfig.io/general.conf
contains a regex location block for CSS files.
Hm, I'm not sure updating the proxy location to be ^~ /
is the best idea here then, as it'd break the settings under nginxconfig.io/general.conf
for asset expiration etc.
I wonder if there's a better way to apply those expirations while still allowing the proxy to work to catch all requests.
Oh, I just realized that I have a few location
directives in the general.conf
.
I see this in the doc:
Among them, the location with the longest matching prefix is selected and remembered.
That's why location /
unable to proxy *.css
files.
I can only find a way to proxy those asset files:
# reverse proxy
location / {
resolver 127.0.0.11;
set $upstream_host my-app;
proxy_pass http://$upstream_host:50050;
proxy_set_header Host $host;
include nginxconfig.io/proxy.conf;
}
# assets, media
location ~* \.(?:css(\.map)?|js(\.map)?|jpe?g|png|gif|ico|cur|heic|webp|tiff?|mp3|m4a|aac|ogg|midi?|wav|mp4|mov|webm|mpe?g|avi|ogv|flv|wmv)$ {
resolver 127.0.0.11;
set $upstream_host my-app;
proxy_pass http://$upstream_host:50050;
proxy_set_header Host $host;
include nginxconfig.io/proxy.conf;
expires 7d;
}
But I don't know what NGINXCONFIG can do in the existing preset. I think you might be able to add a new Reverse Proxy Presets for this.
I made a prototype for this context. (Route all requests)
If you check this option, the location / {
will become location ^~ / {
.
hack way. not recommended.
@MattIPv4 Maybe turn off expires settings when enable Reverse proxy is a good choice?
I don't think disabling it would be the right move, as other domains in the tool might still be using it without a reverse proxy.
I think the best move would be to add a warning to the expires section in the tool when any domain is using the reverse proxy -- we show warnings in a few other places in the tool so I think it makes sense to lean into a standard UI/UX convention here.
With that warning in place, I'm fine with then switching the proxy block to using ^~
, as I believe this was probably the intended behaviour all along. As that's then a regex operator, I believe it'll take precedence over the expiration blocks further down in the config, 'cause the logic for regex blocks is just the first matching block in the config?
Information
https://whatismybrowser.com/w/MLNCGRF
Details
Description
Wrong:
Correct:
Steps to reproduce
Open this link
Expected behavior
I expected to have
^~
afterlocation
directive.See also: https://nginx.org/en/docs/http/ngx_http_core_module.html#location
Screenshots