On 16.08.2010 15:41, Jim Jagielski wrote:
As many know, one thing I've wanted in httpd's proxy for
http is a sort of pre-request ping option (ala what we
have for ajp) and nothing ever worked out fine, for a variety
of reasons.
Anyway, I've gone back to an idea I had a long while ago
and one which ACO and Filip Hanik and I have played around
with and it's very simple: for backends which are http/1.1,
simply use a 100-Continue. If the backend is alive (and
compliant) we should semi-immediately continue with the
request, otherwise we can assume it's down (or so loaded
that it times out) and choose another backend.
I'd like to get this in 2.3.7 before I T&R it, and it will
be optional behavior, not the default, but wanted to give
people a head's up beforehand.
Two remarks:
RFC 2616 says in "8.2.3 Use of the 100 (Continue) Status":
...
Requirements for HTTP/1.1 clients:
...
- A client MUST NOT send an Expect request-header field (section
14.20) with the "100-continue" expectation if it does not intend
to send a request body.
So if the proxy inserts an expectation for 100-continue by itself for
requests without bodies, it possibly is a violation of the spec. In
other words, it is unclear to me how other servers react on such an
expectation for requests without bodies. I'd say the benefit still makes
the experiment worth it if configurable.
The second remark:
If the client already sends such an expectation, we must forward it to
the origin server. In this case I guess we don't want to add a second
expect to the same request (and need to make sure we actually return the
100 to the client instead of only consuming it ourselves).
Regards,
Rainer
