Re: reverse proxy wishlist

> On Dec 9, 2015, at 2:02 AM, jean-frederic clere wrote: > > On 12/03/2015 03:59 PM, 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/

Re: reverse proxy wishlist

On 12/03/2015 03:59 PM, 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 backend

Re: reverse proxy wishlist

On 12/03/2015 07:39 PM, Houser, Rick wrote: > I would definitely expect to see a substantial improvement if the thread > reservation could be delayed until the response headers are fully received. That is something tricky you need to mix blocking and non-blocking of have a bunch (configurable)

Re: reverse proxy wishlist

> On Dec 7, 2015, at 8:32 AM, Plüm, Rüdiger, Vodafone Group > wrote: > So I would go for a pragmatic approach with no sharp line. I guess we can > bundle all balancers we deliver into one module. IMHO we wouldn't lose > anything here In this particular case, I

Re: reverse proxy wishlist

> On Dec 5, 2015, at 9:30 PM, William A Rowe Jr wrote: > > On Sat, Dec 5, 2015 at 3:48 PM, Jim Jagielski wrote: > > > On Dec 4, 2015, at 10:25 AM, William A Rowe Jr wrote: > > > > My observation was that that the mapped pages for

Re: reverse proxy wishlist

On 3 December 2015 14:59:00 GMT, Jim Jagielski wrote: >What would *you* like to see as new features or enhancements >w/ mod_proxy, esp reverse proxy. I'd like to have more options about error responses. Where httpd is reverse proxy for an application that may fail, and I want to have httpd send

Re: reverse proxy wishlist

On Sat, Dec 05, 2015 at 11:01:54AM +, Tim Bannister wrote: > ProxyErrorOverride is a good starting point. Often I want to let through only > some error pages: the ones explicitly coded to be shown to this website's > visitors. If the backend fails and produces an unstyled page of jargon and

Re: reverse proxy wishlist

> On Dec 4, 2015, at 10:25 AM, William A Rowe Jr wrote: > > My observation was that that the mapped pages for 2-6 fundamental socache, > lbmethod or slotmem providers are the same as for a single module due to page > alignment - load any two and you are already wasting

Re: reverse proxy wishlist

On Sat, Dec 5, 2015 at 3:48 PM, Jim Jagielski wrote: > > > On Dec 4, 2015, at 10:25 AM, William A Rowe Jr > wrote: > > > > My observation was that that the mapped pages for 2-6 fundamental > socache, lbmethod or slotmem providers are the same as for a

Re: reverse proxy wishlist

My observation was that that the mapped pages for 2-6 fundamental socache, lbmethod or slotmem providers are the same as for a single module due to page alignment - load any two and you are already wasting kernel resources and memory. I agree that any user agent or content facing modules should

Re: reverse proxy wishlist

I thought the idea of providers and submodules were so that, for example, if someone only used byrequests, for example, they only needed to build and load that specific submodule and nothing else... Not seeing what issue exactly you're trying to address. > On Dec 3, 2015, at 6:25 PM, William A

Re: reverse proxy wishlist

<b...@qqmail.nl> wrote: > > > >> -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 >> >> >>>

Re: reverse proxy wishlist

On Thu, 3 Dec 2015 12:23:24 -0600 William A Rowe Jr wrote: > On Thu, Dec 3, 2015 at 10:32 AM, Nick Kew wrote: > Yup, and I'm not proposing to eliminate the mechanism, I'm proposing > that the existing 'core' subset be codified in fewer, still > lightweight

Re: reverse proxy wishlist

On Fri, Dec 4, 2015 at 10:17 AM, Nick Kew wrote: > > > I'm looking, none of these seem like huge hacks, wondering > > which of them trigger your concern? > > Well, your talk of refactoring config led me to wonder > whether you were proposing another tilt at the whole directory

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

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

te module sitting on the output filter chain, wouldn't it? Rick Houser Web Administration (517)367-3516 > -Original Message- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: Thursday, December 03, 2015 4:42 PM > To: dev@httpd.apache.org > Subject: Re: reverse proxy

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 <wr...@rowe-clan.net&g

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

; To: Apache HTTP Server Development List <dev@httpd.apache.org> > Subject: Re: reverse proxy wishlist > > On Thu, Dec 3, 2015 at 12:36 PM, Houser, Rick <rick.hou...@jackson.com> > wrote: > > An async mod_proxy backend would be huge for my workloads. In the JE