Bug 56925 - ProxyErrorOverride=On causes workers in error state after 500 errors
Summary: ProxyErrorOverride=On causes workers in error state after 500 errors
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_balancer (show other bugs)
Version: 2.4.10
Hardware: All Linux
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2014-09-08 05:09 UTC by cristian.httpd
Modified: 2015-06-23 13:29 UTC (History)
3 users (show)


Attachments
trunk: don't put the backend in error state (by default) when 500/503 is overridden (1.26 KB, patch)
2015-04-13 21:27 UTC, Yann Ylavic 		Details | Diff
2.4.x: don't put the backend in error state (by default) when 500/503 is overridden (1.23 KB, patch)
2015-04-13 21:30 UTC, Yann Ylavic 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description cristian.httpd 2014-09-08 05:09:19 UTC 
Consider the following setup for a reverse proxy. 

ProxyRequests Off
ProxyErrorOverride On
ProxyPass /error !
ErrorDocument 500 /error/500.html

ProxyPass / balancer://cluster/ nocanon
ProxyPassReverse / balancer://cluster/

<Proxy balancer://cluster>
    BalancerMember http://localhost:9001 route=node0 keepalive=On ping=3 retry=60 loadfactor=100
    BalancerMember http://localhost:9011 route=node1 keepalive=On ping=3 retry=60 loadfactor=100

    ProxySet stickysession=JSESSIONID|jsessionid lbmethod=byrequests timeout=90 nofailover=On
</Proxy>

If I generate a request for a buggy page that causes a 500 error, the worker would be put in error state for one minute according to the retry parameter, regardless if subsequent requests are successful. 

However, if I switch ProxyErrorOverride to Off, the worker would not be put in error state after a request that generates a 500 error, and other clients can still use the same worker.

Based on the documentation, if the failonstatus does not contain the 500 status code the worker should not be put in error state in case of a single request generating a 500 error.
Comment 1 cristian.httpd 2015-03-19 00:21:52 UTC 
Hi, is there an update on this ticket? It would be nice to know if it is confirmed as an issue or not.
Comment 2 Florian S. 2015-04-13 07:17:13 UTC 
I can confirm this issue for 2.4.12, came here for the same reason. (With ProxyErrorOverride, worker is put in error state for 500 responses, without ProxyErrorOverride, it is not.)
Comment 3 Yann Ylavic 2015-04-13 21:27:33 UTC 
Created attachment 32648 [details]
trunk: don't put the backend in error state (by default) when 500/503 is overridden

This can be forced by failonstatus, but can't be the default for overridden errors since those come from the backend (and not the scheme_handler).
Comment 4 Yann Ylavic 2015-04-13 21:30:54 UTC 
Created attachment 32649 [details]
2.4.x: don't put the backend in error state (by default) when 500/503 is overridden

Same against 2.4.x.

Can you please test one of these patches (easiest for you) and report if it works as expected?
Comment 5 Yann Ylavic 2015-05-26 14:21:58 UTC 
Committed in r1681694 (backport proposed in r1681765).
Comment 6 cristian.httpd 2015-06-03 09:13:41 UTC 
Hello Yann,
Thank you for fixing this. I tested your fix and it appears to work fine for mod_proxy_http. Can you please fix the same issue for mod_proxy_ajp as well and provide a patch?
Comment 7 Yann Ylavic 2015-06-03 09:38:02 UTC 
Thanks for testing.

The AJP part was done in r1682907 and the whole backported to 2.4.13 in r1683112.
Comment 8 cristian.httpd 2015-06-03 20:40:10 UTC 
Thank you for all the help, I will try to cherry pick it unless 2.4.13 comes soon. Do you know when 2.4.13 will be released ?
Comment 9 Yann Ylavic 2015-06-03 22:13:00 UTC 
Possibly (probably) next week.