We have a couple of backends sitting behind our nginx front ends.
Is it possible to intercept 301 / 302 redirects sent by these backends and have nginx handle them?
We were thinging something alone the lines of:
error_page 302 = #target;
But I doubt 301/302 redirects can be handled the same as 404's etc etc... I mean, error_page probably doesnt apply to 200, etc error codes?
So to summarize:
Our backends send back 301/302s once in a while. We would like to have nginx intercept these, and rewrite them to another location block, where we could do any number of other things with them.
Possible?
Thanks!
You could use proxy_redirect directive:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect
Nginx will still return 301/302 to the client but proxy_redirect will modify Location header and the client should make a new request to the URL given in the Location header.
Something like this should make the subsequent request back to nginx:
proxy_redirect http://upstream:port/ http://$http_host/;
I succeeded in solving a more generic case when a redirect location can be any external URL.
server {
...
location / {
proxy_pass http://backend;
# You may need to uncomment the following line if your redirects are relative, e.g. /foo/bar
#proxy_redirect / /;
proxy_intercept_errors on;
error_page 301 302 307 = #handle_redirects;
}
location #handle_redirects {
set $saved_redirect_location '$upstream_http_location';
proxy_pass $saved_redirect_location;
}
}
Alternative approach, which is closer to what you describe, is covered in ServerFault answer to this question: https://serverfault.com/questions/641070/nginx-302-redirect-resolve-internally
If you need to follow multiple redirects, modify Vlad's solution as follows:
1) Add
recursive_error_pages on;
to location /.
2) Add
proxy_intercept_errors on;
error_page 301 302 307 = #handle_redirect;
to the location #handle_redirects section.
More on proxy_redirect, for relative locations
Case
location /api/ {
proxy_pass http://${API_HOST}:${API_PORT}/;
}
the backend redirects to a relative location, which misses the /api/ prefix
the browser follows the redirection and hits a wall of incomprehension
Solution
location /api/ {
proxy_pass http://${API_HOST}:${API_PORT}/;
proxy_redirect ~^/(.*) http://$http_host/api/$1;
}
Related
I am building my nginx configuration with automated tools like nginx-proxy on docker. There they let me add a custom line inside the location directive.
Simply, I want www.example.com to be 301 redirected to example.com, or generally both http://www.example.com and https://www.example.com should be 301 redirected to https://example.com.
The automated configuration creation results as such:
server {
...
server_name www.example.com;
listen 443 ssl http2 ;
location / {
proxy_pass http://<upstream>;
return 301 $scheme://example.com;
}
}
I notice that there are proxy_pass syntax before return 301 ..., and since its creation is automated, I don't think I can easily modify that (i.e. to make return 301 appear before the proxy_pass syntax.
From nginx documentation:
proxy_pass
Sets the protocol and address of a proxied server and an optional URI to which a location should be mapped.
So, nginx-wise question, since it said "sets", will the 301 redirect be done correcly, even if the redirect came after the proxy_pass syntax ?
From the comment by RichardSmith, it is said that the return syntax will be evaluated first and hence proxy_pass is completely ignored.
So I am trying to set up an nginx default.conf and I'm having trouble using variables. I want to capture the subdomain as the $subdomain variable and use it a few times in the default.conf.
Here is my config:
server {
listen 80;
server_name ~^(?<subdomain>.+)\.example\.com$;
# To allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# To disable buffering
proxy_buffering off;
location / {
rewrite ^/$ /$subdomain/index.html break;
proxy_set_header Host $http_host;
proxy_pass http://minio-server:9000/$subdomain/;
#health_check uri=/minio/health/ready;
}
}
Unfortunately the presence of the $subdomain variable in the location block fails nginx entirely every time. If I were to replace $subdomain in the location block with tester as a static value then everything works.
How to correctly use the $subdomain variable here???
This question is a somewhat of a followup on this issue: k8s-ingress-minio-and-a-static-site. In that issue I was trying to use Ingress to reverse proxy to a minio bucket, but to no avail. Now I'm just trying to go through Nginx directly but my vars ain't workin.
Updates
So it seems the proxy_pass will not resolve the host correctly if there is a variable in the URL.
Tried two things:
set the resolver like so: resolver default.cluster.local. I tried a bunch of combos for the fqdn of the kube-dns but to no avail and kept getting minio-server can't be found.
Simply don't use variables like Richard Smith mentions below. Instead rewrite everything then proxy pass. However I don't understand how this would work and I get very useless errors like so: 10.244.1.1 - - [07/Feb/2019:18:13:53 +0000] "GET / HTTP/1.1" 405 291 "-" "kube-probe/1.10" "-"
According to the manual page:
When variables are used in proxy_pass: ... In this case, if URI is specified in the directive, it is passed to the server as is, replacing the original request URI.
So you need to construct the complete URI for the upstream server.
For example:
location = / {
rewrite ^ /index.html last;
}
location / {
proxy_set_header Host $http_host;
proxy_pass http://minio-server:9000/$subdomain$request_uri;
}
It may be better to use rewrite...break and use proxy_pass without a URI.
For example:
location / {
rewrite ^/$ /$subdomain/index.html break;
rewrite ^ /$subdomain$uri break;
proxy_set_header Host $http_host;
proxy_pass http://minio-server:9000;
}
I'm trying to do a basic NGINX reverse proxy by subdomian, to localhost/folder and am stumped getting it to rewrite my assets+links.
My http://localhost:8080/myapp/ works like a charm, but via NGINX+subdomain it fails on the subfolder assets.
I believe I'm stumped on the 'rewrite' clause for NGINX.
How can I rewrite the HTML going to the client browser to drop the /myapp/ context?
server {
listen 443 ssl;
server_name app1.domain.com;
location / {
rewrite ^/myapp/(.*) /$1 break; # this line seems to do nothing
proxy_pass http://localhost:8080/myapp/;
}
}
I'm expecting my resultant HTML (via https://app1.domain.com) to be rewritten without the subfolder /myapp/, so when assets are requested they can be found instead of a 404 against https://app1.domain.com/myapp/assets/. It should just be https://app1.domain.com/assets/ (which if I manually go there they work)
--thanks.
Feeding from Ivan's response and finalizing my solution as:
server {
listen 443 ssl;
server_name app1.domain.com;
location / {
sub_filter '/myapp/' '/'; # rewrites HTML strings to remove context
sub_filter_once off; # ensures it loops through the whole HTML (required)
proxy_pass http://localhost:8080/myapp/;
}
}
As nginx proxy_pass documentation states:
In some cases, the part of a request URI to be replaced cannot be determined:
...
When the URI is changed inside a proxied location using the rewrite directive, and this same configuration will be used to process a request (break):
location /name/ {
rewrite /name/([^/]+) /users?name=$1 break;
proxy_pass http://127.0.0.1;
}
In this case, the URI specified in the directive is ignored and the full changed request URI is passed to the server.
So with this configuration block after you rewrite /myapp/assets/some_asset URI to /assets/some_asset and use a break flag, nginx ignores /myapp/ suffix on a proxy_pass directive and passes /assets/some_asset request to your backend. However strange it is, what you need is to use this rewrite rule instead:
rewrite ^(/myapp/.*)$ $1 break;
Another (may be even better) solution is to use two location blocks:
location / {
proxy_pass http://localhost:8080/myapp/;
}
location /myapp/ {
proxy_pass http://localhost:8080;
}
I'm using nginx as a reverse proxy for a service running on port 8080 of the local machine. Additionally I need to prefix paths sent to the upstream with /vp. This is simple and I have a working location block for it:
location ~ ^/(.*?)$ {
proxy_pass $scheme://127.0.0.1:8080/vp/$1;
proxy_set_header Host $host;
proxy_redirect $scheme://$host/vp/ $scheme://$host/;
}
So the above would support a url like example.com/resource and work perfectly.
However, I also want to support urls like example.com/vp/resource. For this I have to write another location block or else it would passed to the upstream as /vp/vp/resource which doesn't work.
location ~ ^/vp/(.*?)$ {
rewrite /vp(.*?)$ /$1;
}
The above works and now I have support for urls like example.com/vp/resource.
But I have one last thing I'd like to fix. When a user would access example.com/vp/resource I want the url in the browser to be rewritten to just example.com/resource. My above configuration does not do this and I do not know how to modify it so that it does. I thought the point of rewrite was to rewrite urls seen in the browser but that doesn't seem to be the case.
First I tried change this:
location ~ ^/vp/(.*?)$ {
rewrite /vp(.*?)$ /$1;
}
to this:
location ~ ^/vp/(.*?)$ {
return /$1;
}
And this mostly worked. All URIs starting with /vp would be redirected to ones without which would change the url in the browser. However, this had the side effect of making POST requests not work. This is because the POST request never actually makes it to the upstream server. Instead the POST returns the 301 redirect immediately, without a proxy pass. The browser then GETS the redirect Location and that's the end.
So I needed to selectively return a true 301 only when the request was NOT a POST and when it was I needed to proxy_pass it. After reading the If is Evil I learned I can't use a proxy_pass inside of an if (inside of a location), only return and rewrite. Doing reading on rewrite, I learned that it rewrites the URI of a request but doesn't send it back to the client immediately. Instead it runs the newly rewritten URI against all the location blocks and executes whichever one matches. So in my case I just needed to use a rewrite to execute my original location block.
My final config ended up looking like this:
location ~ ^/vp/(.*?)$ {
if ($request_method = POST ) {
rewrite /vp(.*?)$ /$1;
}
if ($request_method != POST) {
return 301 /$1;
}
}
location ~ ^/(.*?)$ {
proxy_pass http://127.0.0.1:8080/vp/$1;
proxy_set_header Host $host;
proxy_redirect $scheme://$host/vp/ $scheme://$host/;
}
Description:
I want to implement an http server (using nginx) that serves static files.
If the requested file doesn't exist, nginx shall send a request to a service (REST API) that will create the file and return its path.
After that, I want nginx to return the static file that was created.
Question:
What is the best way to return the file after its creation?
So far I managed to do this by changing the REST API in order to return the created file path with the 302 status code and with a location header as a redirect, but I am not sure if this is a good thing to do. Is it?
Is there any nginx-side solution for this? Do I have to create a custom module?
Conf file:
http {
server {
listen 80;
location /files {
try_files $uri #rest;
}
location #rest {
rewrite ^(.*)$ /api/ break;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://localhost:8080;
}
}
}
Edit: Actually, on balance, this should be even simpler:
location #rest {
...
proxy_intercept_errors on;
error_page 404 = $uri;
}
Configure the named location to intercept an "error" coming back (I chose 404), and then using the error_page directive will cause the given URI to be loaded again. Since the file now exists, the request should succeed.
Side note: I had thought try_files $uri #rest $uri would have worked, but an internal redirection only happens for the last argument.
The simplest option here is probably for your REST service to use X-Sendfile/X-Accel to return the relevant URI that Nginx should serve once the file is created. Your REST service could return the target URI using the header X-Accel-Redirect.
In your case, your API could actually just return the same URI it received as the X-Accel-Redirect header, and then Nginx would re-use the same location block and find the file for the subrequest occurring.
If this fails, however, using an internal Nginx location as per the examples at http://wiki.nginx.org/XSendfile and http://wiki.nginx.org/X-accel:
location /files-protected {
internal;
root /path/to/files;
}
and returning the relevant URI to that would also work.