httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: mod_proxy ping docs
Date Wed, 15 Feb 2017 17:12:12 GMT
On Wed, Feb 15, 2017 at 5:28 PM, William A Rowe Jr <> wrote:
> Question...
> BalancerMember parameter "ping":
> "Ping property tells the webserver to "test" the connection to the
> backend before forwarding the request. For AJP, it causes
> mod_proxy_ajp to send a CPING request on the ajp13 connection
> (implemented on Tomcat 3.3.2+, 4.1.28+ and 5.0.13+). For HTTP, it
> causes mod_proxy_http to send a 100-Continue to the backend (only
> valid for HTTP/1.1 - for non HTTP/1.1 backends, this property has no
> effect). In both cases, the parameter is the delay in seconds to wait
> for the reply. This feature has been added to avoid problems with hung
> and busy backends. This will increase the network traffic during the
> normal operation which could be an issue, but it will lower the
> traffic in case some of the cluster nodes are down or busy. By adding
> a postfix of ms, the delay can be also set in milliseconds."
> Do we mean 100-Continue? Or was this actually an "OPTIONS * HTTP/1.1"
> or similar health-check request?

What's done is "100-continue" on the backend side, relevent only
when/limited to ap_request_has_body().

> 100-Continue isn't really a ping-ack
> query, it would only be applicable once a request is sent, and ping
> implies that the health is checked *before* sending the request.

I think it is not meant to do health-check but rather to retry with a
new connection on failure (before 100-continue response, e.g. backend
closed its side of the connection between our reuse and the actual
send), which would not be allowed otherwise for non-idempotent

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message