Nginx – use rewrite nginx matching location with arg key

nginx

I am using one URL for different purposes:

/path/items : returns a list of items
/path/items?id=XXX : redirects to URL /path/items/item?id=XXX

EDIT: Added solution based on Tero's input

I've tried that rule in my nginx conf file:

location ~ / {
    rewrite '^/path/items\?id=([0-9]*)$' /items/item?id=$1? break;
}

When I access the page /path/items?id=XXX, I get the following log:

2016/08/25 14:08:53 [notice] 22903#0: 1 "^/path/items\?id=([0-9])$"
does not match "/path/items", client: XXX, server: local.xxx.ins,
request: "GET /path/items?id=32442305 HTTP/1.1", host: "local.xxx.ins"

I understand from that log that nginx remove the args before doing the match. but I cannot find out how to get a match including the args.

I came up with a solution realy close to Tero's one.

location ~ /(path1|path2|path3) {
    if ($arg_id) {
        rewrite ^ $uri/item break;
     }
     proxy_pass http://local.xxx.ins:8080;
}

Best Answer

You cannot process query strings within rewrite directives. You can only process URI there.

You can try this configuration:

location /path/items {
    if ($arg_item) {
        rewrite ^ /items/item break;
    }
    try_files $uri $uri/ =404;
}

The location /path/items restricts this behavior only to URIs that have /path/items prefix. We test if a query argument item is defined in the HTTP request. If it is, we rewrite the URI. Otherwise we just try the URIs given by the client.

You might need modification of the try_files directive depending on how the items list is made. You might also need a root directive if it is not defined in the server level.

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

nginx try_files – How Does try_files Work in nginx?

try_files tries the literal path you specify in relation to the defined root directive and sets the internal file pointer. If you use for instance try_files /app/cache/ $uri @fallback; with index index.php index.html; then it will test the paths in this order:

$document_root/app/cache/index.php
$document_root/app/cache/index.html
$document_root$uri

before finally internally redirecting to the @fallback named location. You can also use a file or a status code (=404) as your last parameter but if using a file it must exist.

You should note that try_files itself will not issue an internal redirect for anything but the last parameter. Meaning you cannot do the following: try_files $uri /cache.php @fallback; as that will cause nginx to set the internal file pointer to $document_root/cache.php and serve it, but since no internal redirect takes place the locations aren't re-evaluated and as such it will be served as plain text. (The reason it works with PHP files as the index is that the index directive will issue an internal redirect)

Best Answer

Related Solutions

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

nginx try_files – How Does try_files Work in nginx?

Related Topic