Your problem is that you are adding an extra question mark. >From the docs:
> $is_args > “?” if a request line has arguments, or an empty string otherwise Take the extra question mark out of your try_files line. It should look like this: try_files $uri $uri/ /index.php$is_args$args; Moshe On Wed, May 27, 2020 at 9:33 AM petecooper <nginx-fo...@forum.nginx.org> wrote: > Hello. > > I run a PHP + MySQL content management system on Nginx (1.19.0 at time of > writing) and an issue has arisen with the way I'm handing PHP files in some > situations. > > The issue appears to manifest with queries when they are prepended by a > path, where a `?` is prepended. If the queries exist in the root location, > they work as expected. > > Take the two following URIs, note the second has a `path` set, but this > does > not exist on the filesystem. The CMS might, for example, have a path set to > 'articles' or 'blog'.: > > http://subdomain.example.com/?a=b&d=g (No `path`) > http://subdomain.example.com/path/?a=b&d=g (With `path`) > > Running $_GET array gives different results: > > = No `path` = > > array ( > 'a' => 'b', > 'd' => 'g', > ) > > = With `path` = > > array ( > '?a' => 'b', > 'd' => 'g', > ) > > Note the first key in the 'With `path`' example is wrongly prepended with > `?`. > > My Nginx config appears to have been running fine for some time, but my > instinct says there's either a `location` regex that I'm missing, or > something else I've overlooked. I am, unfortunately, not smart enough to > know what I'm doing wrong. > > I have included all my `location` blocks for this `server` so as not to > trigger a conflict from another `location` block, the most relevant two are > the last and second-to-last in the list. > > location ^~ /.well-known/ { > allow all; > default_type "text/plain"; > root /var/www/sites/example.com/subdomain/_well-known/; > try_files $uri $uri/ =404; > } > location /favicon.ico { > access_log off; > log_not_found off; > } > location /robots.txt { > access_log off; > log_not_found off; > } > location ~ /\. { > deny all; > } > location ~ \.svg$ { > #redeclare `add_header` from parent, with modified `style-src` for > SVG > set $csp_svg_1f173340 ''; > set $csp_svg_1f173340 '${csp_svg_1f173340}default-src \'none\';'; > set $csp_svg_1f173340 '${csp_svg_1f173340}frame-ancestors > \'self\';'; > set $csp_svg_1f173340 '${csp_svg_1f173340}style-src \'self\' > \'unsafe-inline\';'; > add_header Content-Security-Policy $csp_svg_1f173340; > add_header Referrer-Policy strict-origin; > add_header Strict-Transport-Security "max-age=31536000; > includeSubDomains; preload"; > add_header X-Content-Type-Options nosniff; > add_header X-Frame-Options SAMEORIGIN; > add_header X-XSS-Protection "1; mode=block"; > } > location / { > index index.html index.php; > limit_except GET HEAD POST { > deny all; > } > try_files $uri $uri/ /index.php?$is_args$args; > } > location ~ ^.+\.php(?:/.*)?$ { > fastcgi_hide_header "X-Powered-By"; > fastcgi_keep_conn on; > fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; > fastcgi_pass unix:/var/run/php/php-fpm74.sock; > fastcgi_split_path_info ^(.+\.php)(/.+)$; > include fastcgi_params; > try_files $uri =404; > } > > I would be grateful if you're able to have a look and see what I might be > doing wrong. Any recommendations for further reading, or pointers to a > 'better' way of handling PHP in this situation are very gratefully > received. > > Thank you in advance, and best wishes to you. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?2,288165,288165#msg-288165 > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx