httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Oliver <acoli...@gmail.com>
Subject Re: trunk "ping" for http proxy
Date Mon, 16 Aug 2010 21:28:57 GMT
Note that it is an option, not a default setting.  The problem with
the heartbeat bit which Red Hat/JBoss use is the unstandardized
proprietary protocol required (http://jboss.org/mod_cluster) with
separate logic to manage it.

The problem with the status url is that it doesn't accomplish the same
thing nor is it that very manageable with multiple contexts (i.e
http://server1:8080/foo http://server1:8081/bar ...).  You'd have to
make a separate request each time.

Purpose:

C = Browser
P = middle apache server
W = destination web server (probably tomcat)

C------>P------->W

C asks for http://myserver/someDatabaseBackedThing
P matches and forwards this request to W with the expect continue and
specified 5 sec expect-continue timeout.  A separate overall proxy
timeout of 1 minute is set.
W returns a continue but then begins to process the request
(CGI/JavaServlet/PHP whatever to the database)
W spends less than a minute and the request is successful

C asks for http://myserver/someDatabaseBackedThing
P matches and forwards this request to W with the expect continue and
specified 5 sec expect-continue timeout.  A separate overall proxy
timeout of 1 minute is set.
W does not return a continue or any kind of response for 5 seconds
P marks that worker dead meat

C asks for http://myserver/someDatabaseBackedThing
P matches and forwards this request to W with the expect continue and
specified 5 sec expect-continue timeout.  A separate overall proxy
timeout of 1 minute is set.
W returns a continue but then begins to process the request
(CGI/JavaServlet/PHP whatever to the database)
W spends more than a minute and the proxy request times out

The case of a dead connector things back out rather nicely and its
clearly distinguishable from a bad script.

-Andy

On Mon, Aug 16, 2010 at 2:52 PM, Jim Jagielski <jim@jagunet.com> wrote:
>
> On Aug 16, 2010, at 1:42 PM, Paul Querna wrote:
>
>> On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski <jim@jagunet.com> 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.
>>
>
> 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
> architecture...
>
>

Mime
View raw message