Hot answers tagged

13

You should almost always use $host, as it's the only one guaranteed to have something sensible regardless of how the user-agent behaves, unless you specifically need the semantics of one of the other variables. The difference is explained in the nginx documentation: $host contains "in this order of precedence: host name from the request line, or host name ...


5

As far as I understood, we can assume that if there is an [example.com] substring in the beginning of the $arg_title variable, we can just safely cut it out. So here is the config that you need: location ~* /pdf/([0-9a-fA-F])([0-9a-fA-F])([0-9a-fA-F])([0-9a-fA-F])([0-9a-fA-F])([0-9a-fA-F]+)\.pdf$ { #First of all we should put pdf path from the request ...


4

Isn't your try_files in the wrong order? Perhaps that's what causing you the headache and the endless cycles, because the file @missing, well, is indeed missing from your filesystem, and redirecting back to $uri indeed must cause an endless cycle for sure? -try_files @missing $uri; +try_files $uri @missing; Nonetheless, if you only have two WordPress ...


3

Apache 2.4 and later has a directive to remove the X-Forwarded-* headers. ProxyAddHeaders off https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyaddheaders


3

Your problem is that browsers don't even send the fragment identifier to the server, so even if Nginx was willing to rewrite based on that, it wouldn't be able to do so because it wasn't provided with that info. I'm really curious about how your previous solution worked with Apache - I just double checked and my Firefox doesn't send the fragment identifier ...


3

JavaScript Single-page apps often use a hash to handle navigation within the app (clicking on a link in the application might update the hash to https://example.com/springApp/#/foo/bar, for example). It's becoming less common as the HTML5 History API becomes well supported, though.


3

You can use a rewrite. For example rewrite all PHP scripts with trailing /: location / { rewrite ^/(.+\.php)(/.+) /$1?$2; try_files $uri $uri/ =404; }


3

AFAIK (but please don't take this for granted), these anchors are processed by the client, and not sent to the webserver. If this is true, you can't alter these via nginx. If you absolutely have to (but again: what's the point of this?), you need to do this at the client side, via JavaScript for example.


2

Sometimes things are starring in your face but you don't see them... The solution is to remove the highlighted http header flag from my root websites vhost below: [...]** add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";**[...] What this basically does is pretty obvious, once you visit the main website 'example....


2

With regards to rewrite rules, those are allowed in the main server config, but they don't effect VirtualHosts. Somewhat hidden in the manual it is mentioned somewhat casually: Note that rewrite configurations are not inherited by virtual hosts. This means that you need to have a RewriteEngine on directive for each virtual host in which you wish to use ...


2

ServerName accepts a scheme as well, e.g. ServerName https://example.com. Changing this in the configuration and restarting Apache did the trick. From the documentation: Sometimes, the server runs behind a device that processes SSL, such as a reverse proxy, load balancer or SSL offload appliance. When this is the case, specify the https:// scheme and ...


2

You need to create a separate VirtualHost for a non-www domain and set redirect from it like this: <VirtualHost *:80> ServerName domain.com Redirect 301 / https://www.domain.com </VirtualHost> Basically, adding the above code to your httpd.conf should solve your problem. Though you might want to consult your OS documentation on ow to ...


2

Since your SSL certificate is not valid for www.example.com, when someone accesses your site using www.example.com, they will get a certificate warning. This happens regardless of whether they are served a redirect or not. Otherwise, it would be possible to create a redirect to any site at all and it would look trustworthy. What you need to do is to either ...


2

Based on your information I would recommend you to try the following rule: rewrite ^/(.+)/(.+)$ /$1/index.php?/$2 last; Every () is a group that can be reached by a variable.


2

Your RewriteCond for the *.443 section has an obvious issue with it. HTTPS (typically) runs on port 443 (as the VirtualHost configuration shows) but your rewrite condition says 'If the server port is not 80, redirect to https://...'. So, hit port 443, ask for content, get told to go to 443 because you're not on 80. That's a loop. RewriteCond %{...


2

Just turned on rewrite log and debug log and found out that your problem is in rewriting to -. Unlike Apache, nginx takes it literally and rewrite request URI to string -. Then it cannot find any location block that matches this URI and uses it's magic configuration "" that just happens to have all the server rewrite rules. So new URI goes through all the ...


2

The URLs in abc.com are generated by the application software running on it, or tracking scripts you get from an external source. You cannot use nginx to make anything to those URLs, since nginx only handles URLs that come to the server, not the URLs that the application software generates.


1

Avoid using if statements, they're not great for performance. Try something like this : ~* means case insensitive regular expression match, and regular expressions can just be literals. If it doesn't work let me know, it will just need a small tweak - not sure if you need the speech marks server { server_name example.com www.example.com; location ~* "^/...


1

You can change (.*) to (.+) .* matches any character (except newline) Quantifier: * Between zero and unlimited times, as many times as possible, giving back as needed [greedy] .+ matches any character (except newline) Quantifier: + Between one and unlimited times, as many times as possible, giving back as needed [greedy] That mean : /...


1

This is a way to do it: RewriteEngine On #redirect all your http trafic to https exept /foo & /bar RewriteCond %{HTTP_HOST} ^example.com RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI} !(/foo|/bar) RewriteRule (.*) https://example.com$1 [R=301,L] #redirect /foo trafic to /bar RewriteCond %{HTTP_HOST} ^example.com RewriteCond %{REQUEST_URI} /foo ...


1

Have you tried this one? location ~ ^/v1/(login|logout) { proxy_pass http://upstream/v1/$1; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } Edit: You may also add the following directive along with your proxy_pass_header Authorization; directive: proxy_set_header Authorization $...


1

What's wrong with this simple one? location /v1/ { proxy_pass http://upstream/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }


1

That's strange. On Ubuntu 15.04's nginx 1.6.2 with all the default modules, I can do location / { rewrite ^/foo… http://example.com permanent; } ...and get the expected redirect. Assuming you have reloaded nginx and disabled your browser cache, are you sure the rewrite is happening in a location block that matches /info-cry…? It's also possible that ...


1

Both URLs hit your final try_files clause: /index.php?q=$request_uri As the file does not exist and the only location block that matches is "/". The regex location block does not match initially, as it does not end with ".php", that is until rewritten by the try_files directive mentioned above. Also, your fastcgi_split_path_info directive does not really ...


1

If the mod_rewrite works in a .htaccess then you should be able to put it in tags with the directory pointing to the dir which you used to put the .htaccess in.


1

Thank you Aaron, your answer helped me a lot. I could confirm the following settings works with my current running postfix setup (stable Ubuntu 14.04). I've added the following to main.cf: # Receive all emails and rewrite the destination because of testing. recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical_maps My ...


1

In main.cf add (removing the existing static map): recipient_canonical_maps = pcre:/etc/postfix/rcpt_canonical_maps In /etc/postfix/rcpt_canonical_maps(replace domain1.com etc with your 'good' domains): if !/^(.*)@(domain1.com|domain2.com|domain3.com)$/ /^(.*)@.*$/ REDIRECT ${1}@spam.example.com endif Please not, i have not tested this, but I'm fairly ...


1

location /rigoplay/ { rewrite ^/rigoplay/yon-(.*)\.mp4$ /rigoplay/index.php?videodata=$1&yonlendir=true last; rewrite ^/rigoplay/(.*)\.mp4$ /rigoplay/index.php?videodata=$1 last; } You don't need if and %1. Nginx automatically adds querystring to rewritten request. You have to use full URI in rewrite.


1

I got it working like this: rewrite ^/fakelocation/(\w*)/(\w*)/(\w*)? /myfile.php?arg1=$1&arg2=$2&arg3=$3 last;


1

Remove the whole conditions node from your rule. You have the same pattern in the condition as in the rule which makes it redundant, except for the negate="true" attribute which is the reason why it didn't work. The rule matches everything, but then the condition blocks everything, so nothing is redirected. Only use conditions if you really need them to ...



Only top voted, non community-wiki answers of a minimum length are eligible