Bug 1309598 - ProxyErrorOverride On disables workers when a 50x error code is returned by the backend server
Summary: ProxyErrorOverride On disables workers when a 50x error code is returned by t...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Web Server 2
Classification: JBoss
Component: mod_cluster, httpd
Version: 2.1.0
Hardware: Unspecified
OS: Linux
medium
high
Target Milestone: CR01
: 2.1.1
Assignee: George Zaronikas
QA Contact: Michal Karm Babacek
URL:
Whiteboard:
Depends On:
Blocks: 1338664
TreeView+ depends on / blocked
 
Reported: 2016-02-18 09:07 UTC by Ingo Weiss
Modified: 2020-06-11 12:48 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When a VirtualHost uses ProxyPass to proxy traffic to the backend uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This issue is fixed.
Clone Of:
: 1338664 (view as bug list)
Environment:
Last Closed: 2019-06-13 09:17:32 UTC
Type: Bug
Embargoed:
dmichael: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JWS-362 0 Major Closed ProxyErrorOverride=On causes workers in error state after 500 errors 2020-03-23 08:37:09 UTC
Red Hat Issue Tracker MODCLUSTER-505 0 Major Closed ProxyErrorOverride=On causes workers in error state after 500 errors 2020-03-23 08:37:09 UTC
Red Hat Knowledge Base (Solution) 2171621 0 None None None 2016-03-29 19:25:42 UTC

Description Ingo Weiss 2016-02-18 09:07:40 UTC
Description of problem:

When a VirtualHost uses ProxyPass to proxy traffic to the backend uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example

Version-Release number of selected component (if applicable):

Apache httpd 2.2.26 from JBoss EAP and mod_cluster 1.2.11.Final

How reproducible:

Always

Steps to Reproduce:
1. Configure a VirtualHost with ProxyPass / balancer://balancername/
2. Add ProxyErrorOverride On
3. Add at least ErrorDocument 500 /error500.html
4. Access the backend normally and the trigger a 500 error

Actual results:

Worker is marked as down and connection is forwarded to another worker, breaking session stickiness. Client receives custom 500 error page as expected.

Expected results:

Second request not being forwarded to a different worker

Comment 3 George Zaronikas 2016-07-17 18:58:32 UTC
Backported upstream patch https://svn.apache.org/viewvc?view=revision&revision=1683112 in order to resolve the issue

Comment 5 Michal Karm Babacek 2016-08-10 23:50:23 UTC
Apparently, single HTTP 500 error code coming from a one worker doesn't break session stickiness:

>hudson@rhel7GAx86-64:~$ curl 'http://192.168.122.172:8746/clusterbench/httpcode/?http_code=200' -c cookie.txt -b cookie.txt
>Done. 
>HTTP Code was: 200
>JVM route: tomcat-7-2
>Session ID: 65F8C139571EF218315BAD6BD94E8D18.tomcat-7-2
>Session isNew: false
>
>hudson@rhel7GAx86-64:~$ curl 'http://192.168.122.172:8746/clusterbench/httpcode/?http_code=200' -c cookie.txt -b cookie.txt
>Done. 
>HTTP Code was: 200
>JVM route: tomcat-7-2
>Session ID: 65F8C139571EF218315BAD6BD94E8D18.tomcat-7-2
>Session isNew: false
>
>hudson@rhel7GAx86-64:~$ curl 'http://192.168.122.172:8746/clusterbench/httpcode/?http_code=500' -c cookie.txt -b cookie.txt
>My Custom 500 page.
>
>hudson@rhel7GAx86-64:~$ curl 'http://192.168.122.172:8746/clusterbench/httpcode/?http_code=200' -c cookie.txt -b cookie.txt
>Done. 
>HTTP Code was: 200
>JVM route: tomcat-7-2
>Session ID: 65F8C139571EF218315BAD6BD94E8D18.tomcat-7-2
>Session isNew: false
>
>hudson@rhel7GAx86-64:~$ curl 'http://192.168.122.172:8746/clusterbench/httpcode/?http_code=200' -c cookie.txt -b cookie.txt
>Done. 
>HTTP Code was: 200
>JVM route: tomcat-7-2
>Session ID: 65F8C139571EF218315BAD6BD94E8D18.tomcat-7-2
>Session isNew: false


Note You need to log in before you can comment on or make changes to this bug.