I have a get route in the form
$app->get('/redirect[/{subject}]', function ($request, $response, $args) {
});
If I make a request to /redirect/server?site=local&name=john
I can get the subject right with
$request->getAttribute('subject')
However, I can't get the query parameters. If I inspect $request->getQueryParams() I get:
[
'/redirect/server?site' => 'local',
'name' => 'john'
]
Whereas I'd be expecting the query params to be
[
'site' => 'local',
'name' => 'john'
]
What am I doing wrong? Perhaps I should specify that the url parameter mustn't accept a question mark?
Edit 1
I've been asked to post my webserver config. I'll have access to that dev machine tomorrow, so this is just a reminder to myself to add said info. However #jmattheis already gave me a hint.
Slim Framework 3 setup for nginx says something along the lines
location / {
try_files $uri /index.php$is_args$args;
}
Whereas I'm using the rewrite snippet that used to be suggested for slim 2 at some point in time:
location / {
try_files $uri $uri/ /index.php?$request_uri;
}
This config has worked fine for me for years, but it happens that I've never tried to parse whatever came after the question mark. It is just now that I have forked an abandoned project that I'm trying to transform raw $_REQUEST parsing into Slim routing methods.
Edit 2
The codebase for the project is in the repo phpPgAdmin6. It's basically a fork of phpPgAdmin that had no route logic, so I'm trying to centralize requests and responses to a given extent, and parse the query string using Slim native methods.
As you found out you need to use
location / {
try_files $uri /index.php$is_args$args;
}
Instead of
location / {
try_files $uri $uri/ /index.php?$request_uri;
}
The second one adds the whole request uri as a query parameter that would result in something like this
index.php?/redirect/server?site=local&name=john
because of that /redirect/server?site was given as query-key.
Related
I have a website with pagination, which chooses the page to display using the 'p' query.
My issue is that
www.example.com/category.html and
www.example.com/category.html?p=1
Are the same content, and are showing as duplicates for SEO purposes, how do i redirect all ?p=1 queries in nginx to their query free counterpart.
Thanks
The value of the p argument is contained in the $arg_p variable. The if statement can be used to test the value of a variable. The actions available in an if block are limited (see this document for details), but a simple return statement is allowed.
So the simplest solution would be to obliterate the query string from any URI which contains p=1, like this:
server {
...
if ($arg_p = 1) {
return 301 $uri;
}
location / { ... }
}
Note that $uri is the normalised request URI, and is already missing the query string.
I have http requests such as the one below being sent to an nginx server:
GET /app/handler?id=1234¶m1=cbd¶m2=234
Now, I want to rewrite the request to a different handler depending on the id param in the request. eg. redirect to handler_even for even ids and handler_odd for odd ids. This is shown below:
GET /app/handler?id=1234¶m1=cbd¶m2=234 => /app/handler_even?id=1234¶m1=cbd¶m2=234
GET /app/handler?id=123¶m1=cbd¶m2=234 => /app/handler_odd?id=123¶m1=cbd¶m2=234
I can do the rewrite using proxy_pass, but I'm unsure how to redirect using the id parameter value. Any idea how I could go about this? Would using "if" be the best way to go about this?
Any pointers would be useful
Rather than use an if directive, you could use a map. To internally rewrite the URI use:
map $arg_id $handler {
default /app/handler_even;
~[13579]$ /app/handler_odd;
}
server {
...
location = /app/handler {
rewrite ^ $handler last;
}
...
}
The map should be located at the same level as your server directive (as shown above), i.e. within the http container.
See this document for details.
I'm new to nginx and I need to setup up a load of 301 redirects each pointing old files to the new ones, like this:
# www.domain.com/products/category/product.php?id=103
# to
# www.domain.com/products/new-category-name/new-product-name.html
To deal with the ? I have the following which seems to be working fine:
if ($args ~ "id=103") {
rewrite ^ /products/new-category-name/new-product-name.html? permanent;
}
How does this look? I'm aware that if is mostly a bad idea in nginx but I don't fully understand why. Is the above rule okay? it seems to work fine. Lastly, I have around 100 of these urls to redirect. Will it be okay to just duplicate this rule for each url?
Thanks
UPDATE
The mapping looks to be a great solution but I'm not sure where to place the code. I currently have the following:
location / {
try_files $uri $uri/ #modx-rewrite;
}
It's stated that any additional rules need to be placed before this location block.
I would sugguest to use the ngx_http_map_module
create a file for the urlmapping, that contains old and new urls, like
/products/category/product.php?id=103 /products/new-category-name/new-product-name.html ;
/products/category2/product.php?id=104 /products/new-category2-name/new-product104-name.html ;
that's easy to maintain. just add a new line for a new mapping and reload your nginx config.
in your nginx config create a location with a mapping like
map $request_uri $newuri {
include /path/to/your/mappingfile;
}
server {
...
location / {
if ($newuri) {
return 301 $newuri;
}
}
}
I'm trying to make a single page website with sinatra in the backend. I want all GET-requests with preferred accept-header "text/html" to return the same page, BUT all requests that wants json to get json-data.
Example:
A GET call to '/users' with accept set to 'text/html' should return index.html.
A GET call to '/users' with accept set to 'application/json' should return the JSON-data with users.
I have tried using a catch-all method for html and using accept-checks like this:
# Generic html giver for angular routing
get //, :provides => 'html' do
pass unless request.preferred_type.to_str == 'text/html'
erb :index
end
# Give users as JSON
get '/users', :provides => 'json' do
pass unless request.preferred_type.to_str == 'application/json'
'["dummy", "array"]'
end
...but it doesn't seem to pass to the second route when preferred_type isn't text/html.
Note: I'm useing the string check on preferred_type, since using request.accept? catches all with browsers giving "*/*" as last accept header.
Oh, it seems like the culprit is:
:provides => 'json'
Without it, the passing works as expected. I guess it's a bug then.
I'm trying to create a simple "Hello World"-like API and for that I need a rule to redirect/rewrite the URL to my API.
Let's say my file is called index.php, so whenever I make a GET to index.php I get a list of items.
The first thing I want to do is to redirect the URL mydomain.com/index.php to mydomain.com/api.
And second, when mydomain.com/api is accessed, I'd like the server to trigger the index.php file without rewriting the URL.
My current code looks like this:
location /api {
rewrite ^ $scheme://$host/index.php permanent;
}
location /index.php{
return 302 www.mydomain.com/api;
}
but it's not working as expected. Why and how can I fix it?
You need two rules for what you're trying to achieve.
The first one, the one that will receive requests and "translate" them to your under-the-hood script, should look like this:
rewrite ^/api\?(.+)$ /index.php?$1 last;
As for the second one, the one that should redirect all your users to the "beautiful" URL:
rewrite ^/index.php\?(.*)$ /api?$1 permanent;
Note that this second rule should be outside any location block and before any of those, as you're willing to redirect the user before anything else.
Cheers
# you don't need a rewrite. Use location with the "=" or exact match
location = /api {
alias /path/to/root;
index index.php;
}
location /index.php {
return 302 www.mydomain.com/api;
}
Hope it helps
Here is the second version of my answer using one redirect and an alias:
location /api {
alias /path/to/root;
index index.php;
}
# replace index.php with api
location /index.php {
rewrite (index\.php)(.*)$ /api$2 permanent;
}
My first solution did not forwarded the args. Reading #alexandernst solution gave a better idea of the problem.