reverse proxy wishlist

[Jim Jagielski]

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, pull in performance and load
data for the backend for a more accurate LB provider. But
what about new LB methods? Any ideas there?

tia.

RE: reverse proxy wishlist

[Houser, Rick]

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 free up a lot of 
associated memory.


Rick Houser
Web Administration
(517)367-3516


> -Original Message-
> From: Plüm, Rüdiger, Vodafone Group [mailto:ruediger.pl...@vodafone.com]
> Sent: Thursday, December 03, 2015 10:50 AM
> To: dev@httpd.apache.org
> Subject: 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 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, pull in performance and load
> > data for the backend for a more accurate LB provider. But
> > what about new LB methods? Any ideas there?
> >
> > tia.

Re: reverse proxy wishlist

[Eric Covener]

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 mpm.  Something like 
> this would allow me to drastically reduce thread counts and free up a lot of 
> associated memory.

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.

Re: reverse proxy wishlist

[Nick Kew]

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 process, when the actual program text page
> of each is a few hundred opcodes, max.

Extensibility.  Flexibility.

They're our biggest single strength when compared to
the likes of nginx/tengine.

> (You can submit that the user could want to replace the bytraffic
> implementation, for example, but I'd counter that they can certainly
> rebuild any mod_lbmethod_core module with the others still using
> stock sources, and deploy their alternative, or they can give their
> custom fork of a provide yet another provider name.)

Someone wanting different functionality shouldn't have to
take on the maintenance headache of hacking into one of
our modules.  We have our API/ABI promise to make life easy
for them introducing their own modules.

> I'm not asking anyone to coalesce these, though.  It was already
> on my rather long list of 'nice to have' along with supporting
> multiple conf mergers per module (effectively allowing 'multiple
> modules' to be a single module and splitting our monstrous core
> server and dir configs into related digestible pieces that rarely
> need to be merged, and optimizing away modules with no conf merge at
> all).  And along with cleaning up the httpd 2.next API, and i18n of
> error output which I am continuing on first once the mod_ssl issues
> for mod_ftp are resolved (my current project).

Hmmm.  There's some nice-to-have in there, but it also sounds like
a big hack.

> Last thought, you might want to share your question with users@?

+1

-- 
Nick Kew

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

[Mike Rumph]

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 11/29/2015 1:00 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Sun Nov 29 21:00:32 2015
New Revision: 1717123

URL: http://svn.apache.org/viewvc?rev=1717123=rev
Log:
Fix doc as spotted by mat in online doc

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml?rev=1717123=1717122=1717123=diff
== 


--- httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml Sun Nov 
29 21:00:32 2015

@@ -39,7 +39,7 @@ in order for it to rebuild correctly.
  
-This module makes it easy to restrict what HTTP methods can
+This module makes it easy to restrict what HTTP methods can be
  used on an server. The most common configuration would be:

Should be "on a server".

Re: reverse proxy wishlist

[William A Rowe Jr]

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 mod_proxy_http2 (nghttp2-based)
engine, as mentioned in another thread - multiple implementations
are always good for ferreting out protocol anomalies.

AIUI in the TLS age of HTTP, there is no forward proxy use case for
HTTP/2 that I can surmise, except as a CONNECT tunnel which 1.1
handled just fine already (AIUI that tunnel can then be a multiplexed
HTTP/2 conversation to the tunneled server.)  So this whole discussion
seems to revolve around reverse proxy backend connection. Windowing
might prove effective at reducing huge connection pools to app servers,
if they can be multiplexed over more heavily loaded fast TCP
connections.

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
and slotmem providers. 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 process, when the actual program text page
of each is a few hundred opcodes, max.

(You can submit that the user could want to replace the bytraffic
implementation, for example, but I'd counter that they can certainly
rebuild any mod_lbmethod_core module with the others still using
stock sources, and deploy their alternative, or they can give their
custom fork of a provide yet another provider name.)

I'm not asking anyone to coalesce these, though.  It was already
on my rather long list of 'nice to have' along with supporting multiple
conf mergers per module (effectively allowing 'multiple modules' to
be a single module and splitting our monstrous core server and dir
configs into related digestible pieces that rarely need to be merged,
and optimizing away modules with no conf merge at all).  And along
with cleaning up the httpd 2.next API, and i18n of error output
which I am continuing on first once the mod_ssl issues for mod_ftp
are resolved (my current project).

I was thinking about some
> sort of active backend monitoring, utilizing watchdog, which
> could also maybe, eventually, pull in performance and load
> data for the backend for a more accurate LB provider.
>

I had the impression there was some effort out there to create a
schema for backend servers to report load in a standardized way,
beyond heartbeat? But I've lost my references.

Last thought, you might want to share your question with users@?

Cheers,

Bill

AW: reverse proxy wishlist

[Plüm , Rüdiger , Vodafone Group]

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 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, pull in performance and load
> data for the backend for a more accurate LB provider. But
> what about new LB methods? Any ideas there?
> 
> tia.

Re: reverse proxy wishlist

[Mark Thomas]

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 backend monitoring, utilizing watchdog, which
> could also maybe, eventually, pull in performance and load
> data for the backend for a more accurate LB provider. But
> what about new LB methods? Any ideas there?
> 
> tia.

With my Tomcat hat on:

HTTP/2 support for mod_proxy_http
HTTP upgrade support for mod_proxy_ajp (we'll need to do work on the Tomcat 
side as well)
Improved WebSocket support in mod_proxy_wstunnel [1].

I'm happy to help out on the Tomcat side of things where required.

Mark

[1] The mod_wstunnel assumes (at least it did the last time I looked at it) 
that all requests under a given URL space will be WebSocket requests. That 
doesn't seem to be the way many apps are being implemented. It would be great 
if mod_proxy would allow both mod_proxy_[ajp|http] and mod_proxy_wstunnel to be 
mapped to the same URL space with the 'right' one being selected based on the 
request.
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: reverse proxy wishlist

[Jim Jagielski]

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  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 mpm.  Something like 
> this would allow me to drastically reduce thread counts and free up a lot of 
> associated memory.
> 
> 
> Rick Houser
> Web Administration
> (517)367-3516
> 
> 
>> -Original Message-
>> From: Plüm, Rüdiger, Vodafone Group [mailto:ruediger.pl...@vodafone.com]
>> Sent: Thursday, December 03, 2015 10:50 AM
>> To: dev@httpd.apache.org
>> Subject: 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 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, pull in performance and load
>>> data for the backend for a more accurate LB provider. But
>>> what about new LB methods? Any ideas there?
>>> 
>>> tia.

RE: reverse proxy wishlist

[Houser, Rick]

> 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 View/Presentation tier (as in MVC).

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

I would think any such backend should forward the response body (or complete 
request without a body) as soon as it comes in, streaming if the content is 
large enough (ex. a PDF).

If I desired to buffer all the data before sending to clients (not applicable 
to me, but I can imagine some use cases), that would be the job of a separate 
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 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 
> 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 mpm.  Something
> like this would allow me to drastically reduce thread counts and free up a 
> lot of
> associated memory.
> >
> >
> > Rick Houser
> > Web Administration
> > (517)367-3516
> >
> >
> >> -Original Message-
> >> From: Plüm, Rüdiger, Vodafone Group
> [mailto:ruediger.pl...@vodafone.com]
> >> Sent: Thursday, December 03, 2015 10:50 AM
> >> To: dev@httpd.apache.org
> >> Subject: 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 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, pull in performance and load
> >>> data for the backend for a more accurate LB provider. But
> >>> what about new LB methods? Any ideas there?
> >>>
> >>> tia.

Re: reverse proxy wishlist

[Jim Jagielski]

> 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 will be interesting to be able to leverage
> and compare a mod_proxy_serf vs a mod_proxy_http2 (nghttp2-based)
> engine, as mentioned in another thread - multiple implementations 
> are always good for ferreting out protocol anomalies.
> 

It's kind of funny... the "need" for http/2 between proxy and
origin seems pretty non-existant. There is a blog post by Cloudflare
somewhere about how they don't see servers talking http/2 to the
backend as anywhere near a driver, since all the things that make
it "important" (koff koff!) between browser and server don't really
apply.

Even so, I do think that re-looking into leveraging serf might
be useful, even if for other reasons.

Re: reverse proxy wishlist

[Jim Jagielski]

> 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 
> and slotmem providers. 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 process, when the actual program text page 
> of each is a few hundred opcodes, max.
> 

Not following you there... what do you mean? You mention the
lbmethods; do you mean instead of having each method be its
own module, making them all one?

Re: reverse proxy wishlist

[William A Rowe Jr]

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 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 mod_proxy_http2 (nghttp2-based)
> > engine, as mentioned in another thread - multiple implementations
> > are always good for ferreting out protocol anomalies.
> >
>
> It's kind of funny... the "need" for http/2 between proxy and
> origin seems pretty non-existant. There is a blog post by Cloudflare
> somewhere about how they don't see servers talking http/2 to the
> backend as anywhere near a driver, since all the things that make
> it "important" (koff koff!) between browser and server don't really
> apply.
>

AIUI the reason for http/2 to ignore the OSI Network definition was that
they knew better, and there is a demand for concurrent requests and
responses.  It seems that fits the fat-pipe of 400 concurrent requests
between a gateway and backend app server more than the few pipes
needed between a web browser and the gateway.  /shrug :)


> Even so, I do think that re-looking into leveraging serf might
> be useful, even if for other reasons.
>

I'd agree, either as the h2, h2c or http/1.1 provider.

Re: reverse proxy wishlist

[William A Rowe Jr]

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 again in
> > 2.next, and not just limited to lbmethod, but also the core socache
> > and slotmem providers. 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 process, when the actual program text page
> > of each is a few hundred opcodes, max.
> >
>
> Not following you there... what do you mean? You mention the
> lbmethods; do you mean instead of having each method be its
> own module, making them all one?
>

Not specific to lbmethods but yes, one mod_lbmethod_core.so provider
of the basic set of 3-4 methods that right now eat up a lot of 64kb process
page mappings for no particular benefit.  The builder could even decide
these
are compiled-in to the base httpd.  We don't dismiss the loadable approach,
we simply decide this subset is effectively baked, and then use the loadable
lbmethod to extend yet another experimental/dynamic/evolving method, from
the ASF or third parties.

RE: reverse proxy wishlist

[Bert Huijben]

> -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, 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 mod_proxy_http2 (nghttp2-based)
> > engine, as mentioned in another thread - multiple implementations
> > are always good for ferreting out protocol anomalies.
> >
> 
> It's kind of funny... the "need" for http/2 between proxy and
> origin seems pretty non-existant. There is a blog post by Cloudflare
> somewhere about how they don't see servers talking http/2 to the
> backend as anywhere near a driver, since all the things that make
> it "important" (koff koff!) between browser and server don't really
> apply.

After having implemented fcgi (server support) and http/2 (server and
client) in Apache Serf I was thinking that it would be nice if H2 would
replace the existing server side protocols.

http/1.1 requires chunking or explicit content-length, while http/2 and fcgi
don't have that requirement.



The reason I implemented the server side of those protocols in Apache Serf
was exactly to allow writing such origins with Serf...

Adding such a backend server process is one of the (many) possible
directions Subversion might take in the future.

Bert

Re: AW: reverse proxy wishlist

[Graham Leggett]

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 need a way for EAGAIN 
to be properly handled with the ability to skip forward back to a hook when we 
come back.

I looked at doing this in the filter stack, which is also possible, but doing 
this generically across the server is better.

Regards,
Graham
--

Re: reverse proxy wishlist

[William A Rowe Jr]

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 for us to map so many ldobjects and text pages into
> > the memory map of a given process, when the actual program text page
> > of each is a few hundred opcodes, max.
>
> Extensibility.  Flexibility.
>
> They're our biggest single strength when compared to
> the likes of nginx/tengine.
>

Yup, and I'm not proposing to eliminate the mechanism, I'm proposing
that the existing 'core' subset be codified in fewer, still lightweight
modules.


> > (You can submit that the user could want to replace the bytraffic
> > implementation, for example, but I'd counter that they can certainly
> > rebuild any mod_lbmethod_core module with the others still using
> > stock sources, and deploy their alternative, or they can give their
> > custom fork of a provide yet another provider name.)
>
> Someone wanting different functionality shouldn't have to
> take on the maintenance headache of hacking into one of
> our modules.  We have our API/ABI promise to make life easy
> for them introducing their own modules.
>

If they are *replacing* our tokens, that's on them.  They can add their
own lbname, e.g. bytraffic-hacked, without rebuilding a core provider.
And I'm not going to propose any of this for backport, in fact I don't plan
to condense the source files at all, only simplify their hook registration
and compile the several providers under a core module umbrella.

> I'm not asking anyone to coalesce these, though.  It was already
> > on my rather long list of 'nice to have' along with supporting
> > multiple conf mergers per module (effectively allowing 'multiple
> > modules' to be a single module and splitting our monstrous core
> > server and dir configs into related digestible pieces that rarely
> > need to be merged, and optimizing away modules with no conf merge at
> > all).  And along with cleaning up the httpd 2.next API, and i18n of
> > error output which I am continuing on first once the mod_ssl issues
> > for mod_ftp are resolved (my current project).
>
> Hmmm.  There's some nice-to-have in there, but it also sounds like
> a big hack.
>

Actually they are the ideas and justifications;

 1. multiple conf sections) right now, a module such as core or mod_ssl
 has a small subset of "key" config directives that change often,
 perhaps in nearly every  block or  level.
 Then there is a majority of directives that never change from either
 the global or first-triggered block (e.g. toggling auth from denied to
 a site-wide global permitted state).  These are merges that just
 should not have to happen on each and every merge.  Directory is
 obviously the worst offender, while Server blocks are merged at
 startup and don't enjoy nearly as much optimization.  Dropping
 any module from the merge list that has a NULL merge should
 speed up directory merges, too.  Unsuitable for backport.

 2. API cleanup) I'm looking at a util_compat.h that would map all of
 our long-deprecated ap_ functions into their apr_ or newer _ex
 equivalents.  And busting up httpd.h, starting with util_strings.h
 Unsuitable for backport.

 3. i18n) You ask about our "strengths", we have little globally until
 we actually internationalize error output.  Most servers beat us
 a long time ago in this respect.  Errors are more confusing than
 learning the few tokens you need to write a config (however, some
 internationalized .conf.in files for descriptive text would be a help.)
 The specific error lookup has can be overridden per-server, giving
 shared hosting providers the ability to let vhost admins grok the
 errors their site is receiving.  It's nothing more than a hash table
 now that we have decorated APn throughout the 2.x and 2.4
 error output, so this one can be considered for backport.

 4. mod_ssl) yes, I know my last Upgrade: TLS/1.0 patch doesn't
 interact with the Protocols directive and h2c, since Protocols
 directive patch failed to pick up the existing mod_ssl Upgrade/
 Connection logic.  Working on that fix right now so that both
 options present just one unified Upgrade/Connection message.
 That fix aught to be backported for completeness.

 5. mod_ftp) several recent mod_ssl changes busted mod_ftp's
 AUTH TLS support - and possibly due to my implicit HOST
 command hack (the result of a HOST command is the same
 221 welcome as an initial connection, so this was a fakeout
 to cause that initial greeting - based on the SNI hostname in
 the case of explicit SSL.)  Both the implicit port 995 and
 plaintext port 21 flavors were and are still working, so it is
 just a matter of better coupling mod_ftp AUTH TLS to 

RE: reverse proxy wishlist

[Houser, Rick]

> 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 stuff is getting bottlenecked on database accesses (or 
similar resources) somewhere in the backend.  The problem is, I deal with 
hundreds of different applications (with both JBoss and Tomcat using the 
mod_proxy backend) and each one performs slightly different.  It would take 
more than a trivial amount of effort to get specifics on whether these are 
blocking before the first byte of the header or before the first byte of the 
content itself ( as in 
https://docs.oracle.com/javaee/6/api/javax/servlet/ServletResponse.html#isCommitted%28%29
 ).  In at least the case of WebSphere Application Server (granted, a 
non-mod_proxy backend), I think there was even an option to control the data 
chunking to have the server either wait for a complete response or to start 
sending it out in pieces.

How the JEE tiers typically work is that one or more non-presentation layers 
first collect all the data needed and perform the business logic -- this would 
typically get called from the Servlet itself (ex. doGet method -- or an 
equivalent spot in a framework).  Then, that display object gets sent to the 
presentation layer (JSP or the like) in the form of an object, where the final 
form is rendered (XHTML, HTML, etc.) strictly from the contents of that object. 
 As the presentation logic is a very small part of the overall execution 
timeline (and should not be making backend calls itself), users typically see 
nothing for a while, then the whole page just pops up.  The headers are a 
similar state, and I suspect (but have not confirmed) they only leave the 
server as a complete set (hence the isCommitted method above).  This is in 
direct contrast to typical LAMP stack setups without a dedicated presentation 
tier (like a simple PHP site), where end users often see a page partially 
render output, pausing at specific database queries.

I would definitely expect to see a substantial improvement if the thread 
reservation could be delayed until the response headers are fully received.  
However, it would take some additional research to figure out how much if any 
of that savings could also be gained by allocating the thread when the response 
headers first start coming in.  That additional research may also be highly 
dependent on the specific backend in question and any options in use.  At least 
under this type of JEE workload, however, I would not expect to see a noticable 
benefit to being able to detach and re-attach the worker threads after we start 
processing the response body.



Rick Houser
Web Administration

> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Thursday, December 03, 2015 12:40 PM
> To: Apache HTTP Server Development List 
> Subject: 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 mpm.  Something
> like this would allow me to drastically reduce thread counts and free up a 
> lot of
> associated memory.
> 
> 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.

RE: No H2 Window updates!

[Bert Huijben]

> -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 the issue of streams with smallish inputs and lost
> WINDOW_UPDATEs.
> 
> Please report back if this works for you. I have another time slot on
Friday
> where I can follow up on it. Thanks.

I haven't traced for other problems yet, but the current
^/httpd/httpd/branches/2.4.x branch does *NOT* the windowing issue for me.

My Subversion testrun still gets stuck on that same 'svnmover' test, unless
I set H2WindowSize to a higher value.

Bert

mod_lua r:regex pattern strings

[Mark Taylor]

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
a Lua feature?

Thanks!
Mark

DER encoded cert no longer supported in 2.4 since 2.4.8

[Rainer Jung]

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 SSL_read_X509() which tries PEM but also DER. After the change, 
the OpenSSL API SSL_read_X509() is used, which only accepts PEM.


Is that problem analysis right? If so we'd need to decide, whether we 
keep it as is (no one complained, so DER seems to be rare) and simply 
document the change in the changelog and migration guide, or whether we 
still need to support DER encoded certs.


IMHO documenting the change would be enough.

Regards,

Rainer