0

I have tried multiple suggestions on this to no avail. I am trying to perform a redirect when a proxy request to a client returns a 307. I am picking up the new endpoint to send to from the Location header of the response from the upstream client, and presumably setting it as the new endpoint to send to, then sending it back to the same client but over a different endpoint. But my issue is I can't seem to initiate a second redirect since I can't see any going out from nginx or hitting the upstream client.

The necessary part of my Nginx config is as below:

            #staging server
            location /staging/mmcallback {
                    allow                   127.0.0.1/32;
                    allow                   XXXX;
                    allow                   XXXX;
                    deny                    all;
                    proxy_buffer_size   64k;
                    proxy_buffers       8 64k;
                    proxy_busy_buffers_size 128k;
                    proxy_http_version  1.1;
                    proxy_set_header    Connection "";
                    proxy_set_header    Host "YYYY.com";
                    proxy_pass      https://staging/mmcallback;
                    proxy_intercept_errors  on;
                    error_page 301 302 307 = @handle_redirects_staging;
            }

            #handle redirects for staging environment on client error
            location @handle_redirects_staging {
                    set $saved_location '$upstream_http_location';
                    proxy_http_version  1.1;
                    proxy_pass_request_body on;
                    proxy_pass      https://staging$saved_location;
            }

staging is an already defined upstream server config. I want a config such that when the first location returns a 301/2/7, it redirects to a second endpoint on same server returned in the Location header. Is there a config am missing? Or anything at all?

Edit: Am seeing the below warning on Nginx logs, hope it helps?:

2020/09/09 12:19:56 [warn] 963#0: *1 upstream server temporarily disabled while connecting to upstream, client: X.X.X.X, server: _, request: "POST /staging/mmcallback/endpoint HTTP/1.1", upstream: "https://[IPV6::99]:443/mmcallback/endpoint", host: "Y.Y.Y.Y:8443"

Sensitive data masked

  • I have no idea if this is a good suggestion, but you could use errorpages with just http meta refresh to the other page :)))) – Orphans Sep 9 at 11:38
  • 1
    @Orphans I can't touch the other end, I have no access to it. Also, its a server to server call with Nginx in the middle, no UIs involved – Peter Sep 9 at 11:42
  • Why do you want nginx to fetch the new URI? This is the job of the client. – Michael Hampton Sep 15 at 23:34
  • @MichaelHampton nginx is the client in this scenario. The general layout is API <-> Nginx <-> Target server. For the above specific scenario, the flow is API -> Nginx -> Target server, and the issue is from Nginx -> Target server where the target server returns the 301/2/7 and Nginx has to fetch/follow that – Peter Sep 16 at 6:18
  • No, I mean the real client, not nginx. – Michael Hampton Sep 16 at 14:51
0

Is the nginx directive proxy_redirect any use here?

So if your proxy was returning a 301 to http://example.com/redirect and you wanted this to really go to https://example2.com/hello, you'd have an entry of:

proxy_redirect http://example.com/redirect https://example2.com/hello;
| | |
  • I tried this, did not work. I am beginning to think its more a limitation of Nginx than a config issue – Peter Sep 10 at 11:19
  • What's the redirection URL that your proxy is returning? Can you give me an example? – jaygooby Sep 10 at 11:33
  • using your example above, the same except with an IPV6 address resolved from the domain name e.g. https://[IPV6_ADDRESS]/hello, and thats it. It doesn't continue from there. I tried testing with a curl request, and the curl request failed, so I think thats the cause. Am using a GCE VM for context – Peter Sep 10 at 17:33
0

I ended up refactoring the code on the upstream client to perform an internal "redirect" i.e. without returning a redirect http code to Nginx, so Nginx config remains the same as of now and redirects are occurring internally upstream.

| | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.