proxy_next_upstream and POSTs

[Jonathan Leibiusky]

Ok. Finally I could work it out, so thanks anyway!

Here is my small contribution to nginx, it is not much, but it is something.

https://github.com/xetorthio/nginx-upstream-idempotent

Thanks everyone for your help, and if you have time and find something
weired in the code, let me know!

Jonathan

On Tue, May 10, 2011 at 11:48 AM, Jonathan Leibiusky <ionathan at gmail.com>wrote:

> Right, that is why after digging for a while I realized I wan't doing it
> the right way.
> Now I wrote a module that will hook into the upstream logic and will set
> all the callbacks to the round-robin callbacks. Only the the peer.free
> callback will call the original round-robin callback and after that will do
> something like:
>
>
> if (r->method == NGX_HTTP_POST) {
>   pc->retries = 0;
> }
>
> by setting retires = 0 I think nginx won't retry and will fail and I will
> be using round-robin logic for all the rest.
>
> My only problem is that in the peer.free callback I don't have access to
> the request struct, so I don't know is the request's method. So now I am not
> sure if the approach is the right one.
>
> Any thoughts on this?
>
>
> On Tue, May 10, 2011 at 11:32 AM, Piotr Sikora <piotr.sikora at frickle.com>wrote:
>
>> Hi,
>>
>>
>>  2. Any good advice on how I should do it? I was thinking on adding the
>>> validation somewhere in ngx_http_upstream_test_next (ngx_http_upstream.c),
>>> something like:
>>> if (r->method == NGX_HTTP_POST) {
>>>  return NGX_DECLINED;
>>> }
>>>
>>
>> Keep in mind that you should decline sending request to another backend,
>> only if you already sent it upstream. There is a bunch of errors (bad
>> gateway, connection timeout, etc) which could lead to the code path in
>> question, for which you should still send request to another backend.
>>
>> Best regards,
>> Piotr Sikora < piotr.sikora at frickle.com >
>>
>>
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://nginx.org/mailman/listinfo/nginx
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20110510/128bab05/attachment-0001.html>