Tweak proxy_next_upstream based on HTTP method

Branden Visser mrvisser at gmail.com
Fri Jul 5 13:46:03 UTC 2013


No it doesn't look like limit_except will allow me to change behaviour of
proxy timeouts or next_upstream based on the HTTP method. Are there any
recommendations on how this could be done aside from my workaround?


On Fri, Jul 5, 2013 at 9:27 AM, Branden Visser <mrvisser at gmail.com> wrote:

> Thanks for the quick reply Maxim. That looks interesting, though in
> particular proxy_next_upstream and proxy_read_timeout don't report to be
> valid in that context. I'll give it a try, perhaps it's just an error in
> the docs.
>
>
> On Fri, Jul 5, 2013 at 9:02 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Fri, Jul 05, 2013 at 08:32:38AM -0400, Branden Visser wrote:
>>
>> > Hi all,
>> >
>> > I was wondering if there is a way to have different proxy_* rules
>> depending
>> > on the HTTP method? My use case is that I want to be a little more
>> > conservative about what requests I retry for POST requests, as they
>> have an
>> > undesired impact if tried twice after a "false" timeout.
>> >
>> > e.g., for GET, I may want to try another when I timeout to the back-end
>> > server after 5s, whereas for a POST request, I may want to simply fail
>> the
>> > POST request after 15s.
>> >
>> > I can work around this by doing specific location blocks for each URL,
>> but
>> > having separate defaults based on HTTP method should be easier to
>> maintain.
>>
>> There is the limit_except directive which might be helpful, see
>> http://nginx.org/r/limit_except.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130705/5263d380/attachment-0001.html>


More information about the nginx mailing list