https://bz.apache.org/bugzilla/show_bug.cgi?id=69776
Bug ID: 69776
Summary: mod_proxy_hcheck should support configurable request
headers
Product: Apache httpd-2
Version: 2.4.65
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_hcheck
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Using a production configuration with several hundred BalancerMember's across
over a hundred <Proxy "balancer://..."> configurations, with the combined
proxies sharing a dozen or so servers. Each of these has hcmethod=HEAD11
hcexpr=ok200 and proxy-specific hcuri=... values.
When actual (non-health check) requests are served through these proxies, these
include the various headers that include how the request is served by the
member - specifically, including the "Host:" header. However, there is no
method (at least apparent) to include a "Host:" or any other headers during the
health check probe.
This leads to issues where the health check may be determining only the health
of a default VHOST, etc., on the member server - which could result in an "OK"
status, where non-health check requests destined for a specific VHOST are
routed to a non-functioning member.
Alternatives that I've considered include:
- Making a mess of virtual hostnames at least local to the Apache HTTP servers,
accounting for each combination of node * member - e.g. node1_vhost1.mydomain,
then ensuring that each member server also is configured to recognize and
respond to that virtual hostname.
- Running a dedicated "health check service" on the default VHOST on each
member server, that can further inspect or take in a custom request URI, then
appropriately respond after exercising further internal checks.
Ideally, mod_proxy_hcheck's BalancerMember (and ProxyHCTemplate) would support
something like a "hcreqheader" that could be specified one or more times.
I.E., I could then pass hcreqheader="Host: website1.example.com".
Reference:
- https://httpd.apache.org/docs/current/mod/mod_proxy_hcheck.html
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
