httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: trunk "ping" for http proxy
Date Mon, 16 Aug 2010 17:42:00 GMT
On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski <> wrote:
> On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote:
>> This basicly sums up the downsides of this approach I see as well.
>> IMHO to avoid a spec violation we can only add the Expect header to
>> requests with request bodies. OTOH these requests hurt most when they
>> fail as we cannot sent the request body for a second time, because
>> we do not have it any longer available in most situations and requests
>> with request bodies are usually not idempotent.
>> On the second issue we only need to take care that we do not add something
>> already there and remove something that client expects to see.
>> One last thing I see is that this only works if the backend is HTTP/1.1:
>> 8.2.3
>> - If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower
>>  , it MUST NOT forward the request and it MUST respond with a 417 (Expectation Failed)
>>  status.
> Yes, the code itself is aware of the limitations of 100-Continue,
> including version and req body considerations... It's not ideal,
> but it's better than the OPTIONS method which I played around
> with earlier...
> Still I think it's useful to add it in, have it disabled by
> default, and see how far we can take it...

I think the only options really are a status URL, with a regex match,
so you can test if the backend has an expected content, and having the
backends advertise/notify the proxy that they are alive.

AFAIK, we don't do a good enough job on the first approach, and this
is how many commercial load balancers test if a destination is alive.

The second approach is done with the heartbeat code, though it would
be nice to support it without requiring multicast.  (ie backends ping
the frontend at a specific URL)

Both of these are painful to handle inside a request cycle -- ideally
they would be handled outside blocking any single request from
finishing or processing.  Doing this week inside the request cycle
just seems out of place.

I guess mod_proxy_x could fork() off a child like mod_cgid and then
check backend statuses asynchronously to requests, but thats a
mountain of work :)

View raw message