You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2014/05/12 14:31:20 UTC
failonstatus only works on backend provided status codes
While trying to use the failonstatus option of a balancer for the first time I noticed that it only works on status
codes provided by the backend not on status codes only set by the proxy (in my case a 502 because the backend timed
out). Is this intentional?
Regards
Rüdiger
Re: failonstatus only works on backend provided status codes
Posted by Ruediger Pluem <rp...@apache.org>.
Yann Ylavic wrote:
> On Tue, May 13, 2014 at 9:20 AM, Ruediger Pluem <rp...@apache.org> wrote:
>> Daniel Ruggeri wrote:
>>> On 5/12/2014 7:31 AM, Ruediger Pluem wrote:
>>>> While trying to use the failonstatus option of a balancer for the first time I noticed that it only works on status
>>>> codes provided by the backend not on status codes only set by the proxy (in my case a 502 because the backend timed
>>>> out). Is this intentional?
>>>
>>> Hi, Ruediger;
>>> Yes, that was the original goal. The use case I was tackling was a
>>> case where a backend application server started accepting HTTP requests
>>> before the Servlets had all completed init(). In that case, the backend
>>> returns a 503.
>>
>> But in case we do ProxyErrorOverride this also fails, because r->status is set to HTTP_OK then. Wouldn't it be better to
>> take care of this and my case, so that the worker is set into error mode in this case as well?
>> Or do you think that this would destroy wanted behavior?
>
> It makes sense to set the worker in error based only on the remote
> status, proxy error (connect, timeout...) is a different criterion
> that may break things...
> But clearly one should be able to also include proxy errors
> (optionally, eg. failonproxyerror=on/off).
>
> The ProxyErrorOverride case is orthogonal imho, although it should be
> fixed to work with failonstatus.
No really. The issue with ProxyErrorOverride and proxy generated errors is the same: r->status is set to HTTP_OK and and
this is the only source available for failonstatus to check. To supply the access_status available in proxy_handler
we would need to change the API as we would need an additional parameter to ap_proxy_post_request. This is something
I would like to avoid. I was thinking around something like the following:
Index: mod_proxy.c
===================================================================
--- mod_proxy.c (revision 1593906)
+++ mod_proxy.c (working copy)
@@ -1200,8 +1200,21 @@
goto cleanup;
}
cleanup:
+ {
+ int saved_status;
+
+ saved_status = r->status;
+ r->status = access_status;
ap_proxy_post_request(worker, balancer, r, conf);
+ /*
+ * Only restore r->status if it has not been changed by
+ * ap_proxy_post_request
+ */
+ if (r->status == access_status) {
+ r->status = saved_status;
+ }
+ }
proxy_run_request_status(&access_status, r);
AP_PROXY_RUN_FINISHED(r, attempts, access_status);
Regards
Rüdiger
Re: failonstatus only works on backend provided status codes
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, May 13, 2014 at 9:20 AM, Ruediger Pluem <rp...@apache.org> wrote:
> Daniel Ruggeri wrote:
>> On 5/12/2014 7:31 AM, Ruediger Pluem wrote:
>>> While trying to use the failonstatus option of a balancer for the first time I noticed that it only works on status
>>> codes provided by the backend not on status codes only set by the proxy (in my case a 502 because the backend timed
>>> out). Is this intentional?
>>
>> Hi, Ruediger;
>> Yes, that was the original goal. The use case I was tackling was a
>> case where a backend application server started accepting HTTP requests
>> before the Servlets had all completed init(). In that case, the backend
>> returns a 503.
>
> But in case we do ProxyErrorOverride this also fails, because r->status is set to HTTP_OK then. Wouldn't it be better to
> take care of this and my case, so that the worker is set into error mode in this case as well?
> Or do you think that this would destroy wanted behavior?
It makes sense to set the worker in error based only on the remote
status, proxy error (connect, timeout...) is a different criterion
that may break things...
But clearly one should be able to also include proxy errors
(optionally, eg. failonproxyerror=on/off).
The ProxyErrorOverride case is orthogonal imho, although it should be
fixed to work with failonstatus.
Regards,
Yann.
Re: failonstatus only works on backend provided status codes
Posted by Ruediger Pluem <rp...@apache.org>.
Daniel Ruggeri wrote:
> On 5/12/2014 7:31 AM, Ruediger Pluem wrote:
>> While trying to use the failonstatus option of a balancer for the first time I noticed that it only works on status
>> codes provided by the backend not on status codes only set by the proxy (in my case a 502 because the backend timed
>> out). Is this intentional?
>
> Hi, Ruediger;
> Yes, that was the original goal. The use case I was tackling was a
> case where a backend application server started accepting HTTP requests
> before the Servlets had all completed init(). In that case, the backend
> returns a 503.
But in case we do ProxyErrorOverride this also fails, because r->status is set to HTTP_OK then. Wouldn't it be better to
take care of this and my case, so that the worker is set into error mode in this case as well?
Or do you think that this would destroy wanted behavior?
Regards
Rüdiger
Re: failonstatus only works on backend provided status codes
Posted by Daniel Ruggeri <DR...@primary.net>.
On 5/12/2014 7:31 AM, Ruediger Pluem wrote:
> While trying to use the failonstatus option of a balancer for the first time I noticed that it only works on status
> codes provided by the backend not on status codes only set by the proxy (in my case a 502 because the backend timed
> out). Is this intentional?
Hi, Ruediger;
Yes, that was the original goal. The use case I was tackling was a
case where a backend application server started accepting HTTP requests
before the Servlets had all completed init(). In that case, the backend
returns a 503.
--
Daniel Ruggeri