Allowing my web server to be aware of retries

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Allowing my web server to be aware of retries

nginx mailing list

We use nginx's retry mechanism on timeout and errors, but we'd like to have some way (custom header \ url param) to make our web server know that the request its handling is actually a retry.

We've tried adding $proxy_add_x_forwarded_for and $upstrea_addr but the first didn't return the correct IP and the second was always empty.
We've also tried using $request_time as a way to heuristically guess if this is a retry but it seems to be calculated once before the first request and reused on the following retries.

Is it possible?

We've nginx plus license if there's a feature we can use there for that.

Thanks!

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Allowing my web server to be aware of retries

Maxim Dounin
Hello!

On Wed, Oct 10, 2018 at 12:16:15PM +0300, Rami Stern via nginx wrote:

> > We use nginx's retry mechanism on timeout and errors, but we'd like to
> > have some way (custom header \ url param) to make our web server know that
> > the request its handling is actually a retry.
> >
> > We've tried adding $proxy_add_x_forwarded_for and $upstrea_addr but the
> > first didn't return the correct IP and the second was always empty.
> > We've also tried using $request_time as a way to heuristically guess if
> > this is a retry but it seems to be calculated once before the first request
> > and reused on the following retries.
> >
> > Is it possible?

As long as you are using proxy_next_upstream mechanism for
retries, what you are trying to do is not possible.  The request
which is sent to next servers is completely identical to the one
sent to the first server nginx tries - or, more precisely, this is the
same request, created once and then sent to different upstream
servers as needed.

If you want to know on the backend if it is handling the first
request or it processes a retry request after an error, a working
option would be to switch proxy_next_upstream off, and instead
retry requests on 502/504 errors using the error_page directive.  
See http://nginx.org/r/error_page for examples on how to use
error_page.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx