Handling redirects among upstream servers

Server NGINX
1

Hello,

I’m trying to configure Nginx to access a cluster of application servers
using a simple proxy with multiple application servers in the upstream.
The
application servers use a REST api for object storage and retrieval, and
use
301 redirects among the nodes of the cluster for load balancing. A
client
can connect to server A, then get a redirect to server B, where the
request
will be handled.

This fails when nginx is used as a proxy in this case:

  • the client connects through the proxy and gets connected to server A

  • A returns a 301 with one of the other servers in the Location header

  • Nginx rewrites the location header, so information about which node
    the
    client is supposed to connect to is lost

Does Nginx offer a solution for this? Can nginx handle the 301 itself
without the client ever knowing the redirect happend? Would it be
possible
to store the redirect into a client cookie which is read during the next
request and forces nginx to connect to a particular upstream server?

Thank you,

Posted at Nginx Forum:

2

Hello!

On Fri, Nov 07, 2014 at 05:11:44AM -0500, zappa wrote:

request and forces nginx to connect to a particular upstream server?
In no particular order:

  • You can avoid changes to the Location header, or control them as
    needed. The flexibility provied by the proxy_redirect directive
    should be enough to preserve information needed. See
    Module ngx_http_proxy_module for details.

  • You can instruct nginx to forward requests to another node
    by itself, using the X-Accel-Redirect header. This may be a
    good solution if you are willing to rewrite application servers to
    use features provided by nginx.

  • Redirections can be intercepted using the error_page and
    proxy_intercept_errors directives (I wouldn’t recommend this
    though).

–
Maxim D.
http://nginx.org/

3

Unfortunately I’m not able to change the behaviour of the upstream
servers,
these are a closed-source commercial product and come as-is.

I’ll look into the proxy_redirect to see if I can preserve the server to
redirect to in some way, something like a GET argument or cookie.

I just found out about the Lua module as well. I’m pretty fluent at Lua
so
I’ll see if the module offers the tools to solve my problem - maybe I
can
forge X-accel-redir headers before Ngix handles the response and trick
it
into thinking these were generated by upstream.

Thank you,

Posted at Nginx Forum:

4

Hello!

On Fri, Nov 07, 2014 at 02:05:38PM -0500, zappa wrote:

Btw, why is it you don’t recomment using the error_page method?

It’s an error-prone approach.

–
Maxim D.
http://nginx.org/

5

Btw, why is it you don’t recomment using the error_page method?

Posted at Nginx Forum:

6

I suppose it has to do with the fact that error_page masks errors coming
from the backend, impersonating them with nginx.
If nginx shows a 404 when the backend actually generated it, and you
digged
improperly into the logs, you might be fooled by that and get lost when
trying to trace the error.

If you decide to use per-backend error pages (to help differentiating
where
the error comes from), then the whole thing becomes useless…

Thus, you need to know what you are doing: masking errors from the
backend
is IMHO a double-edged sword.

B. R.

7

Ok, thanks for pointing that out.

Things are working for me now with an error_page handler for 301s only,
so
I’ll stick with this setup for now.

Ico

Posted at Nginx Forum: