httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: trunk "ping" for http proxy
Date Mon, 16 Aug 2010 18:52:15 GMT

On Aug 16, 2010, at 1:42 PM, Paul Querna wrote:

> 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
>>>  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.

Well, OPTIONS is the defacto "HTTP ping" but it's also considered
a "request" (afaik), and so things like keepalives, etc matter.
That was the issue I ran into is that checking with OPTIONS
doesn't totally remove the problem, esp for non-keepalive
connections or one-shots, and then you need to worry if that
last OPTIONS forced a connection that was in keepalive mode
to close and all that junk....

What I just committed is not the ideal solution, but like you
said, the real way to do this is non-trivial with the current

View raw message