On Wed, Feb 15, 2017 at 5:28 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > Question... > > http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass > > 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 requests... --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
