When configuring mod_proxy_hcheck to use hcmethod=options, the hcuri is ignored. Configuration example: <Proxy balancer://test> BalancerMember https://www.example.com/ hcmethod=OPTIONS hcuri=/path/test </Proxy> Access log on health check target: [24/Apr/2019:18:33:12 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" "-" Meanwhile, changing the hcmethod to either GET or HEAD shows the hcuri parameter is respected. For example: <Proxy balancer://test> BalancerMember https://www.example.com/ hcmethod=GET hcuri=/path/test </Proxy> [24/Apr/2019:18:35:33 +0000] "GET ///path/test HTTP/1.0" 404 466 "-" "-" <Proxy balancer://test> BalancerMember https://www.example.com/ hcmethod=HEAD hcuri=/path/test </Proxy> [24/Apr/2019:18:36:17 +0000] "HEAD ///path/test HTTP/1.0" 404 159 "-" "-" rfc2616 states that the OPTIONS method can be used to determine the capability of a specific resource but that a * can be used simply as a ping, so this may be by design. "If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server." However, it would be useful to mirror the functionality of the GET and HEAD hcmethods and have the OPTIONS hcmethod respect the hcuri.
Created attachment 36626 [details] Patch Hi, could you try the attached patch? Its purpose is to behave the same with OPTIONS, HEAD or GET when an hcuri is configured, and fallback to "*" for OPTIONS if hcuri is not provided.