Re: mod_serf is in trunk

2007-11-13 Thread Graham Leggett
On Tue, November 13, 2007 6:34 am, Paul Querna wrote: I've added mod_serf in r594425: http://svn.apache.org/viewvc?view=revrevision=594425 I've grown exceptionally... tired of looking at mod_proxy. mod_serf is nice and tight at 440 lines or so. With just a little more work, I think it

Re: mod_serf is in trunk

2007-11-13 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Graham Leggett Gesendet: Dienstag, 13. November 2007 11:28 An: dev@httpd.apache.org Cc: dev@httpd.apache.org Betreff: Re: mod_serf is in trunk On Tue, November 13, 2007 6:34 am, Paul Querna wrote: I've added mod_serf in r594425:

Re: Please just apply my one-liner fix to bug #42035 and be done with it, no?

2007-11-13 Thread Dominique Quatravaux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Trawick wrote: I'll see that your fix is proposed for backport to 2.0.x, and developers will have a chance to approve it. Thank you *so* much. Don't waste so much of your patience or others' over a one line patch which you can apply to new

keepalive connections and exiting MPM processes

2007-11-13 Thread Jeff Trawick
When the MPM process handling the connection is or will be exiting, we can incorrectly tell the client that the connection will be held open after the current request. This can result in user intervention (retry the POST?) or failures for some requests sent subsequently on that connection. The

RE: mod_serf is in trunk

2007-11-13 Thread Axel-Stephane SMORGRAV
Message d'origine- De : Paul Querna [mailto:[EMAIL PROTECTED] Envoyé : mardi 13 novembre 2007 05:34 À : dev@httpd.apache.org Objet : mod_serf is in trunk I've added mod_serf in r594425: http://svn.apache.org/viewvc?view=revrevision=594425 I've grown exceptionally... tired of

Re: keepalive connections and exiting MPM processes

2007-11-13 Thread Plüm , Rüdiger , VF-Group
-Ursprüngliche Nachricht- Von: Jeff Trawick Gesendet: Dienstag, 13. November 2007 14:31 An: dev@httpd.apache.org Betreff: keepalive connections and exiting MPM processes When the MPM process handling the connection is or will be exiting, we can incorrectly tell the client

Re: keepalive connections and exiting MPM processes

2007-11-13 Thread Jim Jagielski
On Nov 13, 2007, at 8:30 AM, Jeff Trawick wrote: When the MPM process handling the connection is or will be exiting, we can incorrectly tell the client that the connection will be held open after the current request. This can result in user intervention (retry the POST?) or failures for some

Re: keepalive connections and exiting MPM processes

2007-11-13 Thread Jeff Trawick
On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: -Ursprüngliche Nachricht- Von: Jeff Trawick Gesendet: Dienstag, 13. November 2007 14:31 An: dev@httpd.apache.org Betreff: keepalive connections and exiting MPM processes When the MPM process

Re: mod_serf is in trunk

2007-11-13 Thread Jim Jagielski
On Nov 12, 2007, at 11:34 PM, Paul Querna wrote: I've added mod_serf in r594425: http://svn.apache.org/viewvc?view=revrevision=594425 I've grown exceptionally... tired of looking at mod_proxy. mod_serf is nice and tight at 440 lines or so. With just a little more work, I think it could

Re: mod_serf is in trunk

2007-11-13 Thread Sander Striker
On 11/13/07, Paul Querna [EMAIL PROTECTED] wrote: I've added mod_serf in r594425: http://svn.apache.org/viewvc?view=revrevision=594425 Nice! I've grown exceptionally... tired of looking at mod_proxy. mod_serf is nice and tight at 440 lines or so. A cool low number. Fits snugly with the

Re: mod_serf is in trunk

2007-11-13 Thread Jim Jagielski
On Nov 13, 2007, at 8:55 AM, Axel-Stephane SMORGRAV wrote: Just out of curiosity, how would you do this with mod_serf: ProxyPass /foo http://127.0.0.1/ ProxyPassReverse /foo http://127.0.0.1/ ProxyPassReverse /foo http://localhost/ I think the idea is that mod_serf is not intended to be

Re: mod_serf is in trunk

2007-11-13 Thread Justin Erenkrantz
On Nov 13, 2007 6:06 AM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: I agree here. While I would see a benefit of providing a http(s) client API to httpd via serf and thus getting rid of the somewhat strange way mod_proxy_http does its requests to a backend system ,I see no benefit at all

Re: mod_serf is in trunk

2007-11-13 Thread Mads Toftum
On Tue, Nov 13, 2007 at 10:47:53AM -0500, Jim Jagielski wrote: I think the idea is that mod_serf is not intended to be a complete replacement for mod_proxy *at this time*... It's a cool start and a basis to build on. The name makes me think of it as a provider module like httpd - in fact I

Re: mod_serf is in trunk

2007-11-13 Thread Justin Erenkrantz
On Nov 13, 2007 11:10 AM, Mads Toftum [EMAIL PROTECTED] wrote: The name makes me think of it as a provider module like httpd - in fact I think that'd be quite useful (especially going by Justins reluctance to add it to apr-util which would have been my preferred location). Exposing some

Re: mod_serf is in trunk

2007-11-13 Thread Jim Jagielski
On Nov 13, 2007, at 10:39 AM, Justin Erenkrantz wrote: I find that mod_proxy is incredibly complex and doesn't even do the things that it claims to do properly. But it does NOT do the stuff it doesn't claim to do quite well :) Agreed that mod_proxy has the potential of joining the

Re: keepalive connections and exiting MPM processes

2007-11-13 Thread Akins, Brian
On 11/13/07 8:30 AM, Jeff Trawick [EMAIL PROTECTED] wrote: * Note that the condition evaluation order is extremely important. @@ -212,7 +214,8 @@ (!apr_table_get(r-subprocess_env, nokeepalive) || apr_table_get(r-headers_in, Via)) ((ka_sent =

Re: mod_serf is in trunk

2007-11-13 Thread Akins, Brian
On 11/13/07 11:28 AM, Jim Jagielski [EMAIL PROTECTED] wrote: Agreed that mod_proxy has the potential of joining the ranks of mod_rewrite and mod_ssl as the Modules Most Likely To Make One Lose Their Minds And Run Screaming Hysterically Through The Halls. We found it much easier to write our

Re: mod_serf is in trunk

2007-11-13 Thread Ruediger Pluem
On 11/13/2007 05:13 PM, Justin Erenkrantz wrote: On Nov 13, 2007 11:10 AM, Mads Toftum [EMAIL PROTECTED] wrote: The name makes me think of it as a provider module like httpd - in fact I think that'd be quite useful (especially going by Justins reluctance to add it to apr-util which would

Re: svn commit: r594659 - /httpd/httpd/trunk/modules/proxy/mod_lbmethod_rr.c

2007-11-13 Thread Ruediger Pluem
On 11/13/2007 10:55 PM, [EMAIL PROTECTED] wrote: Author: jim Date: Tue Nov 13 13:55:05 2007 New Revision: 594659 URL: http://svn.apache.org/viewvc?rev=594659view=rev Log: Add extremely butt-ugly sub-mod that exists simply to show how to use providers in sub-mods to extend lbmethods in

Re: mod_serf is in trunk

2007-11-13 Thread Ruediger Pluem
On 11/13/2007 04:39 PM, Justin Erenkrantz wrote: On Nov 13, 2007 6:06 AM, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote: I agree here. While I would see a benefit of providing a http(s) client API to httpd via serf and thus getting rid of the somewhat strange way mod_proxy_http does its

Re: svn commit: r594659 - /httpd/httpd/trunk/modules/proxy/mod_lbmethod_rr.c

2007-11-13 Thread Jim Jagielski
On Nov 13, 2007, at 5:11 PM, Ruediger Pluem wrote: On 11/13/2007 10:55 PM, [EMAIL PROTECTED] wrote: Author: jim Isn't this an endless loop if all workers (standby *and* not standby) are in error mode? I guess it is reasonable to return NULL in this case and let mod_proxy_balancer

Re: svn commit: r594659 - /httpd/httpd/trunk/modules/proxy/mod_lbmethod_rr.c

2007-11-13 Thread Jim Jagielski
On Nov 13, 2007, at 5:14 PM, Jim Jagielski wrote: On Nov 13, 2007, at 5:11 PM, Ruediger Pluem wrote: On 11/13/2007 10:55 PM, [EMAIL PROTECTED] wrote: Author: jim Isn't this an endless loop if all workers (standby *and* not standby) are in error mode? I guess it is reasonable to

Re: mod_serf is in trunk

2007-11-13 Thread William A. Rowe, Jr.
Ruediger Pluem wrote: On 11/13/2007 04:39 PM, Justin Erenkrantz wrote: I find that mod_proxy is incredibly complex and doesn't even do the things that it claims to do properly. Rather than spend an inordinate amount of time trying to fix it, I think we'd be better off trying to go in a