reverse proxy wishlist

I put out a call on Twitter regarding this, but wanted to close the loop here as well. What would *you* like to see as new features or enhancements w/ mod_proxy, esp reverse proxy. I was thinking about some sort of active backend monitoring, utilizing watchdog, which could also maybe, eventually,

RE: reverse proxy wishlist

An async mod_proxy backend would be huge for my workloads. In the JEE space I deal with, much more time is spent waiting on the application backends then with the clients, especially now that we have the event mpm. Something like this would allow me to drastically reduce thread counts and

Re: reverse proxy wishlist

On Thu, Dec 3, 2015 at 12:36 PM, Houser, Rick wrote: > An async mod_proxy backend would be huge for my workloads. In the JEE space > I deal with, much more time is spent waiting on the application backends then > with the clients, especially now that we have the event

Re: reverse proxy wishlist

On Thu, 3 Dec 2015 10:09:08 -0600 William A Rowe Jr wrote: > Most stock/core implementations shouldn't > change if a user wants to plug in 'yet another' option, but there is > really no excuse for us to map so many ldobjects and text pages into > the memory map of a given

Re: svn commit: r1717123 - /httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

No problem. I took care of this along with other typos and grammar corrections in r1717786 and r1717800. Thanks, Mike On 12/2/2015 10:37 AM, Marion & Christophe JAILLET wrote: Will fix. Sorry for not seeing it myself. CJ Le 02/12/2015 15:28, Mike Rumph a écrit : Comment below. On

Re: reverse proxy wishlist

On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski wrote: > > What would *you* like to see as new features or enhancements > w/ mod_proxy, esp reverse proxy. HTTP/2 support, of course :) It will be interesting to be able to leverage and compare a mod_proxy_serf vs a

AW: reverse proxy wishlist

How about an async proxy that frees up the thread while waiting on a slow backend? Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Jim Jagielski [mailto:j...@jagunet.com] > Gesendet: Donnerstag, 3. Dezember 2015 15:59 > An: httpd > Betreff: reverse proxy

Re: reverse proxy wishlist

On 2015-12-03 14:59, Jim Jagielski wrote: > I put out a call on Twitter regarding this, but wanted to > close the loop here as well. > > What would *you* like to see as new features or enhancements > w/ mod_proxy, esp reverse proxy. I was thinking about some > sort of active

Re: reverse proxy wishlist

Thx! assuming slow backends, how would you like httpd to handle it: should it just slurp in the data from the backend and buffer it and send it to the client all in one go? Should it instead forward data as soon as it gets it? > On Dec 3, 2015, at 12:36 PM, Houser, Rick

RE: reverse proxy wishlist

> assuming slow backends My workload isn't so much backends slowly and steadily producing data on each connection, but significantly long pauses before delivering any content at all. The "slow" vs "paused" backend seems more applicable to something like a PHP backend without a

Re: reverse proxy wishlist

> On Dec 3, 2015, at 11:09 AM, William A Rowe Jr wrote: > > On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski wrote: > > What would *you* like to see as new features or enhancements > w/ mod_proxy, esp reverse proxy. > > HTTP/2 support, of course :) It

Re: reverse proxy wishlist

> On Dec 3, 2015, at 11:09 AM, William A Rowe Jr wrote: > > My personal wish list is that we eliminate module bloat by coalescing > alternative "standard" implementations into a single module again in > 2.next, and not just limited to lbmethod, but also the core socache >

Re: reverse proxy wishlist

On Thu, Dec 3, 2015 at 3:20 PM, Jim Jagielski wrote: > > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr > wrote: > > > > On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski wrote: > > > > What would *you* like to see as new features or

Re: reverse proxy wishlist

On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski wrote: > > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr > wrote: > > > > My personal wish list is that we eliminate module bloat by coalescing > > alternative "standard" implementations into a single module

RE: reverse proxy wishlist

> -Original Message- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: donderdag 3 december 2015 22:20 > To: dev@httpd.apache.org > Subject: Re: reverse proxy wishlist > > > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr > wrote: > > > > On Thu, Dec 3,

Re: AW: reverse proxy wishlist

On 3 Dec 2015, at 15:50, Plüm, Rüdiger, Vodafone Group wrote: > How about an async proxy that frees up the thread while waiting on a slow > backend? This is generic httpd thing, not restricted to mod_proxy. From what I have seen it shouldn't be difficult, we just

Re: reverse proxy wishlist

On Thu, Dec 3, 2015 at 10:32 AM, Nick Kew wrote: > On Thu, 3 Dec 2015 10:09:08 -0600 > William A Rowe Jr wrote: > > > Most stock/core implementations shouldn't > > change if a user wants to plug in 'yet another' option, but there is > > really no excuse

RE: reverse proxy wishlist

> Out of curiosity, is it usually time to first byte where the delays show up? > I am wondering if there is a big bang-for-the-buck enhancement possible there > that doesn't prereq changes to some of the areas where hopping on and off the > thread is more complicated. Ultimately, most of this

RE: No H2 Window updates!

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: woensdag 2 december 2015 15:45 > To: dev@httpd.apache.org > Subject: Re: No H2 Window updates! > > Please find with r1717641 version 1.0.9-DEV of mod_http2 in trunk and > branches/2.4.x > that fixes

mod_lua r:regex pattern strings

Hi all, I spent some time trying to figure out why 'something/(\w+)' wasn't matching my uri, but [[something/(\w+)]] does. This, \w is not one of the listed valid escape characters, but does in fact seem to be escaped to something. Does anyone have an explanation for this behavior? Is it simply

DER encoded cert no longer supported in 2.4 since 2.4.8

I did a 2.2 to 2.4 migration today. The old 2.2 server was using a certificate file, which was DER encoded and the new 2.4 one didn't like it. It seems support for DER encoded certs was removed in 2.4.8 as a side effect of r1573360 (bckport of r1553824). The certificate in 2.2 is read using