httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <>
Subject re: ping for http in mod_proxy
Date Wed, 13 Feb 2008 17:23:27 GMT

> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski  
> Gesendet: Mittwoch, 13. Februar 2008 17:07
> An:
> Betreff: ping for http in mod_proxy
> I've started looking at adding "ping" support for
> mod_proxy_http to complement whats in mod_proxy_ajp...
> The idea is to send a simple OPTIONS * to the backend
> and hope for a reply.
> The rub is that I've been working on 2 separate
> implementations: one talks direct to the socket and the
> other basically tries to do what ap_proxy_http_request()
> and ap_proxy_http_process_response() does, as far
> as using brigades, etc... The former is much further
> along, btw.

We cannot use the socket approach since we need to be able to
handle SSL backend connections and this requires the brigades - filters

> In any case, both implementations can have what I can
> envision as some "weird effects" as far as how they
> should actually work in the real world. For example,
> should it honor force-proxy-request-1.0 and/or
> proxy-nokeepalive, and, if so, how does that affect

I think the ping is of limited use for HTTP/1.0 / non keepalive requests.
I see it mainly as a measure to avoid race conditions with keepalive
connections that get closed just in the moment as the request is being sent.
The only benefit I would see for HTTP/1.0 / non keepalive requests would be
that a successful connect call (we always create a new connections in this case)
does not guarantee us that you get *any* response (in a timely manner). This could
be because the connect is queued up on the backend in the connection backlog
or in an application specific request queue and will be never processed.

> the subsequent "real" request... In other words,
> it's not as clean as AJP which has a "real" ping.
> And all this is wondering whether or not it's
> really useful in the 1st place...
> So before I go any further, any comments or ideas
> on whether is is even a Good Idea or not... I'm starting
> to have 2nd thoughts :)

It is a good idea for certain purposes and I really appreciate that you
work on this. This issue is still on my when-I-got-time-TODO list.
If not done until then, maybe something for the hackathon to work on.



View raw message