Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

might this be a debian bug? i can't reproduce with apr-included.

Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
> Hi,
> 
> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>  wrote:
>> Hi Stefan,
>>
>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
>>> this seems to be a tough bone to chew. Therefore we need to go deeper:
>>> - can you compile the module so that we see line numbers in the trace?
>>
>> Do you have any idea how to arrange this? I've no idea how to pass the
>> -ggdb option through Apache.
> 
> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
> 
>>
>>> - which apr version are you using?
>> this one:
>> https://packages.debian.org/jessie/libapr1
> 
> Could you also build libapr1 with this same flags?
> 

Re: svn commit: r1779578 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml

[Stefan Eissing]

> Am 20.01.2017 um 12:45 schrieb Luca Toscano :
> 
> 
> 
> 2017-01-20 10:45 GMT+01:00 Stefan Eissing :
> 
> > Am 20.01.2017 um 10:35 schrieb Luca Toscano :
> >
> >
> >
> > 2017-01-20 10:11 GMT+01:00 ste...@eissing.org :
> >
> > > Am 20.01.2017 um 09:45 schrieb elu...@apache.org:
> > >
> > > Author: elukey
> > > Date: Fri Jan 20 08:45:40 2017
> > > New Revision: 1779578
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1779578=rev
> > > Log:
> > > Added more details to mod-proxy-http2's doc
> > >
> > > Modified:
> > >httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > >
> > > Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > > URL: 
> > > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml?rev=1779578=1779577=1779578=diff
> > > ==
> > > --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml (original)
> > > +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml Fri Jan 20 
> > > 08:45:40 2017
> > > @@ -41,9 +41,14 @@
> > > have to be present in the server.
> > >
> > > mod_proxy_http2 works with incoming requests
> > > -over HTTP/1.1 and HTTP/2 requests. If mod_http2
> > > -handles the frontend connection, requests against the same HTTP/2
> > > -backend are sent over a single connection, whenever possible.
> > > +over HTTP/1.1 and HTTP/2 requests. In both cases, requests proxied
> > > +to the same backend are sent over a single connection
> > > +whenever possible (namely when the connection can be re-used).
> > > +
> > > +mod_proxy_http2 will not use the HTTP/2 protocol
> > > +when the frontend requests use HTTP/1.1.
> > > +This means that HTTP/2 will be used to proxy requests to a capable 
> > > backend
> > > +only when the frontend requests use the same protocol.
> > >
> >
> > Not correct. Maybe my explanation was not good. mod_proxy_http2 will always 
> > use HTTP/2 in the backend connection. That connection will however only do 
> > one request at a time if the frontend is HTTP/1.1.
> >
> > No no it is me being slow to understand HTTP/2 related things :)
> >
> > So mod-proxy-http2 will always use HTTP/2 with a "capable" backend, but it 
> > will not exploit its full potential when the frontend requests are HTTP/1.1 
> > (for example "translating" multiple proxied HTTP/1.1 requests into HTTP/2 
> > streams over the same TCP connection).
> >
> > Better? If not I can revert everything and leave you do it, might be better 
> > :)
> 
> Nonono. No easy way out: :)
> 
> You got it right, except one tiny detail: the backend *needs* to talk HTTP/2, 
> there is no fallback to HTTP/1.1 by mod_proxy_http2. Which might be a feature 
> for the future, or a folding of http/2 support into mod_proxy_http (far 
> future).
> 
> 
> So the info was there but my brain for some reason didn't pick it up :)
> 
> I reworded the documentation in http://svn.apache.org/r1779609, hope that it 
> is better this time! 

Thanks! Excellent!

> 
> Luca

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without 
patches?

Greets,
Stefan

Excuse my typo sent from my mobile phone.

> Am 20.01.2017 um 13:04 schrieb Stefan Eissing :
> 
> Different apr versions? Might there have been a bugfix affecting us?
> 
>> Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
>> :
>> 
>> might this be a debian bug? i can't reproduce with apr-included.
>> 
>>> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
>>> Hi,
>>> 
>>> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>>>  wrote:
 Hi Stefan,
 
> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
> this seems to be a tough bone to chew. Therefore we need to go deeper:
> - can you compile the module so that we see line numbers in the trace?
 
 Do you have any idea how to arrange this? I've no idea how to pass the
 -ggdb option through Apache.
>>> 
>>> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
>>> 
 
> - which apr version are you using?
 this one:
 https://packages.debian.org/jessie/libapr1
>>> 
>>> Could you also build libapr1 with this same flags?
>>> 
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Re: Alternate versioning proposal: patch line releases

[Graham Leggett]

On 20 Jan 2017, at 2:15 AM, Jacob Champion  wrote:

> Ignore the versioning number then; that's not really the core of my proposal. 
> The key points I'm making are
> 
> - introduce the concept of a low-risk release line

We have always had this, the current low-risk release line is called v2.4.x.

> - formally tie said release lines to test suite expansion, in a way that does 
> not impede current contributors to 2.4.x

We have always had this. The test suite is called httpd-test and covers all 
versions of httpd.

> - introduce a stable cadence with as little risk to end users as possible

We have always had this.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:05 PM, Jim Jagielski  wrote:
> Bill wrote:
>
>>I think one of our disconnects with 2.4 -> 2.6 is that in any other 
>>framework, there would be
>> no ABI breakage in 2.6. That breakage would be deferred to and shipped as 
>> 3.0.
>
> Huh? For just one single, simple example, what about APR??

Those are the rules of APR today.

httpd today compiles against either apr-1 or apr-2.

I don't understand your question?

> Are we going to now redefine the standards of semantic versioning??

Maybe this will help illustrate our conflicting perspectives on versioning;

  w.m.n.x

I understand your interpretation as
w == wow factor (major breakage)
m = minor (also major breakage)
n = subversion (new features + enhancements, no breakage)

While I understand versioning as
m = major (major breakage)
n = minor (avoid breakage, new features + enhancements)
x = subversion (feature stable, bug + regression fixes only)

I understand you (and perhaps Graham) are arguing there is no need for x?

I argue there is no need for w.

Are we going to move to a model where we have four part designations?
Or can we move to a model where version-minor represents *frequent*
and less disruptive releases to incorporate enhancements?

Re: Reset out x.minor.z definition of 'minor' at httpd?

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 4:04 AM, Graham Leggett  wrote:
> On 19 Jan 2017, at 11:43 PM, William A Rowe Jr  wrote:
>
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>> would be deferred to and shipped as 3.0.
>>
>> The httpd project choose to call 2.minor releases as breaking
>> changes. Due to poor design choices, or frequent refactorings,
>> this essentially shifted our release numbering schema down one
>> digit. So 2.6.0 is not an enhancement release, but a major release
>> in the general understanding of these things. This might be the root
>> of Jim's and my failure to come to any consensus.
>
> I don’t see any relationship between poor design choices / frequent 
> refactorings and a decision made in the late 1990s on a version numbering 
> system.

I do. Remember that the version numbering elected for 2.0 was based on
the direct and recent experience of 1.2.x and 1.3.x. There was no API
or ABI assurance throughout 1.2.x until 1.3.12-1.3.14 time frame
(which became the ABI final 1.3.x representation).  Third party
modules would have to be rebuilt, and sometimes patched, between
subversion releases.

Understanding that context is necessary to understand why 2.0
numbering was adopted. Floating ABIs during 2.{odd} releases, fixed
ABIs during 2.{even} releases balanced the desires for a messy
development phase and a stable maintenance phase. When you look at
early (2.0.0 - 2.0.36) development as an initial {odd} Floating
ABI/API period, it makes sense.


>> Right now, there are a number of gratuitous breaking changes on trunk
>> that change binary ABI. I'm considering a trunk fork to preserve these
>> changes (branches/3.x-future/?) and reverting every change to trunk/
>> which was otherwise a no-op. Namespace, decoration, anything that
>> prevents a user from loading a 2.4.x module in 2.next. And then we
>> can look at what is a valid reason to take us to 3.0.
>
> -1 (veto).

To be clear, procedural decisions can't be vetoed. But specific code
changes can be vetoed.

I can veto and revert each individual commit on trunk which breaks the
API or ABI in an unnecessary manner, pointing at that specific
breakage, and invite the committer to propose the change using the
existing interfaces. Even if that commit dates back soon after the
2011 fork. Where the code is accepted in 2.4.x, I can offer the
author's own 2.4.x backport commit to align their work in an API
stable manner to what is shipping and finally trusted. If it was good
enough to ship in 2.4, there better be an awfully good reason for a
code divergence. In almost every case, it was a sloppy trunk/ commit
and some careful thought applied to how to introduce it into 2.4.x.

And no, you can't then veto such specific vetos. The window to veto
code is before the ASF releases the code.

For forward-ports, you would look awfully silly vetoing a patch
accepted in 2.4.x.

In light of your objection, I won't proceed with a preservation
branch, but take the veto knife directly to trunk.


> As you are well aware, the jump from v2.0 to v2.2, from v2.2 to v2.4, and the 
> jump from v2.4 to v2.6 involves breaking changes, and this is a well 
> established and stable pattern that is well understood by our end users. The 
> “problem” you’re trying to solve does not exist.

There is nothing in httpd which is stable, and 2.4.x certainly hasn't
been well established. Not even 50% of Apache httpd deployments use
2.4.x almost four years later, and 2.4.25 looks so considerably
different than 2.4.1 that it cannot be called a maintenance branch. It
is impossible to identify from "2.4" what point in its evolution is
causing a reported issue without knowing the subversion. A handful of
2.4.x releases walked out the door without some significant regression
- not a proud track record. So this problem which I'm trying to solve
is clearly present.

The second inherent problem you sum up below also certainly exists;


> Arbitrarily reverting the work of others displays a profound lack of respect 
> for those members, committers and contributors to the ASF who have 
> contributed to our codebase. This behaviour discourages collaboration between 
> the community and project, and puts this project at risk.

Not releasing their contributions puts the project at risk of having
contributors walk away from offering further contributions. That was
well established in earlier threads this past month, and originates
from a pattern where trunk/ is not released. My goal is simply a
better user experience trusting they can make subversion upgrades with
no disruption (which has not been possible throughout 2.4.x), also
trusting frequent minor version upgrades to deliver new features, and
treating all significant disruption as major version releases. As one
example. the auth directive block-scope changes were significantly
disruptive to reserve such changes for a major 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:46 PM, Eric Covener  wrote:
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr  
> wrote:
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>> would be deferred to and shipped as 3.0.
>>
>> The httpd project choose to call 2.minor releases as breaking
>> changes. Due to poor design choices, or frequent refactorings,
>> this essentially shifted our release numbering schema down one
>> digit. So 2.6.0 is not an enhancement release, but a major release
>> in the general understanding of these things. This might be the root
>> of Jim's and my failure to come to any consensus.
>>
>> Right now, there are a number of gratuitous breaking changes on trunk
>> that change binary ABI. I'm considering a trunk fork to preserve these
>> changes (branches/3.x-future/?) and reverting every change to trunk/
>> which was otherwise a no-op. Namespace, decoration, anything that
>> prevents a user from loading a 2.4.x module in 2.next. And then we
>> can look at what is a valid reason to take us to 3.0.
>
> The  "why" missing here is presumably to allow a 2.6 to be cut from
> trunk. But in that case, why not just fork it from 2.4 w/o a major nor
> magic cookie bump and let 2.4 become the more conservative stream?

Just so we are all in agreement, 2.4 has been neither conservative nor
maintenance in any conventional sense, for the past four years. Instead
we have users relying on the stable 2.2 release which we will discard
midyear, 4 1/2 years after 2.4 had shipped.


> New major/minor downstream releases can jump to 2.6 without much fuss,
> and current ones can try to track closer to current 2.4.x as they age.

What I'm proposing is that 2.6.0, 2.8.0, 2.10.0 (or we get out of odds/evens
at this point) are rapid feature releases, no less often than once a year.
For some arbitrary period, perhaps a year, fixes are applied to 2.prior.n+1
and yes, those can be tracked. Users can pick the .zero release to grab
the new features now, or wait for .1 or .2 to pick up any regression fixes.
But within two years, not four, 2.prior would be abandoned as 2.current
has been stabilizing (no features after .0) and 2.next (new features) is
about to be released.

This is closer to the model at most other ASF projects.


> We can find some new religion about how trunk work if some concise
> policy doc appears that we can all agree on.

That's the next step after concluding these dialogs, to weave together the
desires of the divergent committers' interests.


On Fri, Jan 20, 2017 at 3:09 AM, Stefan Eissing
 wrote:
>
> Just some brainstorming:
>
> LTS/Stable/Feature branches
>
> 2.2.x/2.4.x/2.6.xfor now

Note 2.2.x is not LTS. It is EOL July.

> 2.2.x/2.6.x/2.8.xif we think new features in 2.6 are stable and want to 
> add more features
> 2.4.x/2.4.x/2.6.xif we end LTS for 2.2, the new LTS can be a stable branch

So 2.4.x again is implicitly unstable.

> 2.2.x/2.4.x/2.8.xin extreme cases, we could ditch a feature branch and 
> move on.

Note that I'm suggesting *much* more frequent version minor releases.

I'd like to see us get *all* new features in users hands within 12
months of first commit.
Not the current pattern not those few which are backported and
destablizing to the
current release - vs those which are not backported, not tested, and
destablizing to
current vs. trunk repository contents.

I think it obviates the need for {even} {odd} if we move rapidly from
2.5.0-beta to
2.5.1-beta to 2.5.2-GA - branch trunk at 2.5.2-GA or 2.5.1-beta for
all new feature
work toward 2.6.0 and ensure 2.6.0-beta gets shipped in months, not a
half decade.

> - we continue working in trunk
> - backports to LTS/stable branches as now, review then commit
> - backports to feature branches: commit, then review
> - LTS is the support promise, stable/feature can move more freely
> - Feature is completely "experimental", we make no promises
> - Distros can support stable longer than we do, which is basically the model 
> they are doing now for their LTS.
> - people will argue for more than 1 LTS release, but I think that is too much 
> for the project, more something for a commercial undertaking

Note I'm suggesting that 2.current and 2.prior get fixes. We can leave the
hassle of backporting further than that to commercial or other endeavors, there
should be no point in time where the choice between those two is worse than
staying back at 2.ancient.

Note I'm suggesting that feature is 2.5.0-beta, 2.5.1-beta, right up until we
declare 2.5.x-GA. That release no longer gets enhancement/features, but
at that point we already have 2.6.0-beta trunk to keep bringing in the new
features.

This might look midyear like;

2.2.x - end of life, abandoned
2.4.x-GA - stable legacy
2.5.2-GA - stable (following a 2.5.0-beta & 2.5.1-beta of features/enhancements)
trunk - not released 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke  wrote:
> I don't know any framework/language/library out there that handles it that 
> strictly. Nginx, or Ruby, or PHP, or whatever...
>
> From x.y.z to x.y.z+1, retain full compatibility.
>
> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, 
> break internal API if absolutely needed
>
> From x.y.z to x+1.0.0, break anything you want.
>
> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, 
> and some of these are features, while other are big architectural overhauls. 
> The former are for 2.6, and the latter very clearly belong into 3.0. There's 
> no reason why both can't be worked on concurrently.

That's what I'm proposing... a model where x.y.[0-#] releases remain consistent,
like all the packages you mention above, and unlike httpd.

I liked your highlight of "if [absolutely] needed". That's where our
trunk (2.next)
has spent four years diverging from 2.current, mostly unnecessarily.

The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
examples, such backports aren't even acceptable) means that it *could* have
stayed consistent on our 2.next trunk.

Re: rfc7231 - content-md5

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
 wrote:
> RFC 7231 has retired Content-MD5.
>
> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
> or INFO and retire it at the next minor release ?

Removing what, precisely? Content-MD5 headers aren't implemented in trunk.

Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
for MD5 hashed
digest auth keys. So removing this altogether will break mod_auth_digest in a
manner that breaks existing user auth.

Re: [Bug 60071] Child httpd processes crash with Segmentation fault when enabling more than 1 healthcheck

[Jim Jagielski]

Cool!

Yann, I see this as a show-stopper for 2.4.26... Do you
agree? Would you like to propose this (and the 2 other
commits) for backport to close this bug.

Thx!

> On Jan 20, 2017, at 2:21 AM, bugzi...@apache.org wrote:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60071
> 
> --- Comment #41 from Endika  ---
> Hello!
> 
> Great news!!! With the last patch after 21 hours and 38 tests i've got no
> errors!!!
> 
> So it seems to be fixed!!
> 
> Good work!!!
> 
> Thanks
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.
> -
> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
> For additional commands, e-mail: bugs-h...@httpd.apache.org
> 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 21:37 schrieb Graham Leggett :
> 
> On 20 Jan 2017, at 7:47 PM, David Zuelke  wrote:
> 
>> I'd actually like to question the whole practice of porting features back to 
>> older branches. I think that's the core reason why trunk is in total 
>> disarray, and why no substantial releases have been made. There is just no 
>> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
>> just backport whatever you want.
> 
> The reason this is bad is because Apache httpd comes with a module ecosystem 
> - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that 
> the ABI can break, and therefore all modules that depend on that version must 
> be recompiled. This includes modules that are closed source and offered by a 
> proprietary vendor, or are open source but provided in binary form by a 
> distro.
> 
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if 
> that feature does not break existing behaviour in any way. This is entirely 
> reasonable, convenient, and what we’ve been doing since the 1990s.

Agree to the plan. I can see only one exception to this and that is the 
experimental HTTP/2 support. The introduction of slave connections is NOT 
ENTIRELY backward compatible. I try to make this as compatible as possible, but 
there are limits.

>> [...]

>> I have said this in the other thread that hasn't gotten much traction ("A 
>> new release process?"). The PHP team was in the exact same spot as HTTPD a 
>> few years ago. No substantial progress, stale branches, no light at the end 
>> of the tunnel, and a lot of fighting.
> 
> We’ve had a significant amount of progress, a trunk that is so stable that 
> almost all fixes and features can be backported to v2.4 without any fear of 
> incompatibility, and the “fighting” is limited to very few individuals.
> 
> We’re not broken, we don’t need fixing.

Agreed.

> 
> Regards,
> Graham
> —
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 21:40 schrieb Jim Jagielski :
> 
> 
>> On Jan 20, 2017, at 3:36 PM, Jim Jagielski  wrote:
>> 
>> 
>> If I really was the dictator Bill tries to insinuate that I am,
>> I would simply branch 2.5 *right now* off of trunk.
> 
> In fact, I'd announce 2.5-alpha "immediately" as what's
> in trunk... with a set schedule that 2.6-Beta1 is tagged 2
> months later and a goal that 2.6-GA be announced at
> ApacheCon Miami.
> 
> But this all implies that 2.5/2.6 not be the huge restructure/re-
> factor envisioned by some.

Let's sort out what will be in it and what everyone is willing to commit to in 
that time frame. Define what 2.6 will be with all the restrictions on time and 
effort that we can do. Then we can have a look at it and see if it's worthwhile 
for us and our users to do.

I hope that leads to a more fruitful discussion. Debating castles in the sky is 
not what I am interested in.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

> On 20 Jan 2017, at 20:49, William A Rowe Jr  wrote:
> 
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>  wrote:
>> RFC 7231 has retired Content-MD5.
>> 
>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
>> or INFO and retire it at the next minor release ?
> 
> Removing what, precisely? Content-MD5 headers aren't implemented in trunk.

That is odd. I have in 

Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1779019

Quite a few:

> ./modules/cache/mod_cache.c:"Content-MD5",
> ./modules/filters/mod_brotli.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_deflate.c:
> apr_table_unset(r->headers_in, "Content-MD5");
> ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./modules/filters/mod_filter.c:
> apr_table_unset(r->headers_out, "Content-MD5");
> ./modules/lua/mod_lua.c:apr_table_unset(r->headers_out, 
> "Content-MD5");
> ./server/core.c:apr_table_setn(r->headers_out, "Content-MD5",
> ./server/protocol.c:apr_table_unset(rnew->headers_in, "Content-MD5");

Did I fuck up my repo in an epic way?

Dw

rfc7231 - content-md5

[Dirk-Willem van Gulik]

RFC 7231 has retired Content-MD5.

Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN or 
INFO and retire it at the next minor release ?

Dw.

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Graham Leggett]

On 20 Jan 2017, at 4:29 PM, William A Rowe Jr  wrote:

>>> Right now, there are a number of gratuitous breaking changes on trunk
>>> that change binary ABI. I'm considering a trunk fork to preserve these
>>> changes (branches/3.x-future/?) and reverting every change to trunk/
>>> which was otherwise a no-op. Namespace, decoration, anything that
>>> prevents a user from loading a 2.4.x module in 2.next. And then we
>>> can look at what is a valid reason to take us to 3.0.
>> 
>> -1 (veto).
> 
> To be clear, procedural decisions can't be vetoed. But specific code
> changes can be vetoed.
> 
> I can veto and revert each individual commit on trunk which breaks the
> API or ABI in an unnecessary manner, pointing at that specific
> breakage, and invite the committer to propose the change using the
> existing interfaces.

This would be an abuse of the veto mechanism - the veto is to protect the 
project, not force other people to do work on your behalf, whether “invited” to 
or not.

In a case like this, what you’d be expected to do is write and commit patches 
that fixed any cases you felt was unnecessary yourself, and have those patches 
reviewed by the rest of the project in the normal way.

> In light of your objection, I won't proceed with a preservation
> branch, but take the veto knife directly to trunk.

As per our rules a veto requires a technical justification. Breaking changes 
are allowed on trunk, and so the fact the change is breaking is not in itself 
sufficient justification for a veto.

>> As you are well aware, the jump from v2.0 to v2.2, from v2.2 to v2.4, and 
>> the jump from v2.4 to v2.6 involves breaking changes, and this is a well 
>> established and stable pattern that is well understood by our end users. The 
>> “problem” you’re trying to solve does not exist.
> 
> There is nothing in httpd which is stable, and 2.4.x certainly hasn't
> been well established. Not even 50% of Apache httpd deployments use
> 2.4.x almost four years later, and 2.4.25 looks so considerably
> different than 2.4.1 that it cannot be called a maintenance branch. It
> is impossible to identify from "2.4" what point in its evolution is
> causing a reported issue without knowing the subversion. A handful of
> 2.4.x releases walked out the door without some significant regression
> - not a proud track record. So this problem which I'm trying to solve
> is clearly present.

I disagree, sorry.

> Finally the fact that httpd's last release was Feb '12 indicates to me
> a project at risk.

The last releases occurred in Dec ’16 and Jan ’17 respectively.

If you want to see trunk released, let’s branch and release v2.5.x in 
anticipation of v2.6.x.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 9:26 AM, William A Rowe Jr  wrote:
> 
> 
> Just so we are all in agreement, 2.4 has been neither conservative nor
> maintenance in any conventional sense, for the past four years. Instead
> we have users relying on the stable 2.2 release which we will discard
> midyear, 4 1/2 years after 2.4 had shipped.
> 

We are NOT in agreement. You just saying so is not proof of
the fact, nor constantly repeating it does not mean that "we
are all in agreement".

Stop trying to steamroll this Bill... it's not productive.
If you put half as much effort into actually coding stuff
in httpd as you do on these long, rambling rants, things
would be much better.

All this crap about redefining minor, and number and all
that is wasteful and simply constantly changing the goal
posts and does NOTHING to address the issue at hand.

Re: Alternate versioning proposal: patch line releases

[Jim Jagielski]

> On Jan 20, 2017, at 10:43 AM, Eric Covener  wrote:
> 
> On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr  
> wrote:
>> Many if not most developers disagree with you, most developers agree that
>> adding features and enhancements is disruptive. 2.4.x adds features and
>> enhancements to every release, and is therefore not low-risk, and absolutely
>> not "as little risk as possible".
> 
> Maybe a [POLL] thread is in order, specifically for the topic of
> enhancements/stability in 2.4 and ignoring aspirations about a new
> versioning system or 3.0.
> 
> e.g.
> 
> 2.4.x is:
> [X] evolving just fine

I'd like to see the new stuff currently "locked away" in trunk
get out to our end users. The only expedient way to do so lately
has been to backport to 2.4

If we could commit to releasing 2.6 in short order, then there
would not need to be the "demand" to backport as much.

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 12:47 PM, David Zuelke  wrote:
> 
> 
> I'd actually like to question the whole practice of porting features back to 
> older branches. I think that's the core reason why trunk is in total 
> disarray, and why no substantial releases have been made. There is just no 
> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
> just backport whatever you want.
> 
> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the 
> process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? 
> It's already "stable". It doesn't need more features that suddenly change 
> behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users 
> are looking for).

Ummm... that's kind of the goal. You are telling us nothing we
don't already know. The issue is that 2.6 has been stuck in
a holding pattern, and it is unfair to our users, and our
developers, to have good, useful features locked in trunk
with no hope of reaching outside for some unknown amount of
time.

So, you say, the question is Why Not Work On 2.6 And Push Getting
That Out. The reason is because some people then want/desire/demand
huge restructurings in 2.6, which means, of course, that forking/
branching off 2.5/2.6 is the EASY part. The hard part is controlling
the urge to then go "wild" on 2.5/2.6, which drastically increases
the time until we finally get GA. And some people also want NO NEW
FEATURES in 2.4 during this whole timeframe. I know, crazy.

If I really was the dictator Bill tries to insinuate that I am,
I would simply branch 2.5 *right now* off of trunk. And then
say the goal is to get 2.5 stable enough to go GA as 2.6... no
big restructuring, no huge and invasive API changes. These are
all good, and needed, but if the goal is to make 2.4 our 2.2-like
"stable and no new features" branch, we need a 2.6 that happens
SOON.

And finally, I don't believe at ALL that things are as dire as
Bill claims nor that trunk is "in total disarray" as you state.

I do appreciate the insight related to PHP. It goes well with
the insight on how lots and lots of other projects handle
this. But what works for PHP, a language, may not necessarily
work for httpd, a commodity server.

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 3:37 PM, Graham Leggett  wrote:
> 
> 
> We’ve had a significant amount of progress, a trunk that is so stable that 
> almost all fixes and features can be backported to v2.4 without any fear of 
> incompatibility, and the “fighting” is limited to very few individuals.
> 
> We’re not broken, we don’t need fixing.
> 

Here here!!

++1!

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 3:36 PM, Jim Jagielski  wrote:
> 
> 
> If I really was the dictator Bill tries to insinuate that I am,
> I would simply branch 2.5 *right now* off of trunk.

In fact, I'd announce 2.5-alpha "immediately" as what's
in trunk... with a set schedule that 2.6-Beta1 is tagged 2
months later and a goal that 2.6-GA be announced at
ApacheCon Miami.

But this all implies that 2.5/2.6 not be the huge restructure/re-
factor envisioned by some.

Re: JSON for mod_status

[Daniel Gruno]

On 01/18/2017 03:48 PM, Daniel Gruno wrote:
> On 01/18/2017 03:19 PM, Luca Toscano wrote:
>>
>>
>> 2017-01-18 10:56 GMT+01:00 Daniel Gruno > >:
>>
>> On 01/17/2017 07:33 PM, Jim Jagielski wrote:
>> > It all depends on what Bill decides regarding mod_bmx and if
>> > it is something we intent to backport to 2.4.x
>> >
>> > Still not sure on how to *use* BMX, or how other modules
>> > "hook in" (right now we have several modules hook into
>> > mod_status so the "how" is well known and documented), so
>> > I would require some sort of docs in addition to the actual
>> > code, of course.
>>
>> Some JFDI in the meantime; https://httpd.apache.org/server-status
>>  :)
>> JSON: http://httpd.apache.org/server-status?view=json_status
>> 
>>
>>
>> Really nice work! I'd really like to see (if the author agrees :P) some
>> mod_lua scripts shipped with the httpd release and referenced in our
>> documentation. 
> 
> Hey, it's ALv2, always has been - if we wanna ship it, so be it :)
> It's at https://github.com/Humbedooh/server-status at the moment, and
> needs a tiny bit of cleanup if it's to be shipped.

I tidied up the code and refactored the JSON format.
HTML view: http://httpd.apache.org/server-status
JSON: http://httpd.apache.org/server-status?view=json
Extended JSON:
http://httpd.apache.org/server-status?view=json=true (LOT OF
DATA :p)

Feedback/suggestions are most welcome.
I'll likely donate this to httpd after FOSDEM if there's an interest in
that.

With regards,
Daniel.

> 
> With regards,
> Daniel.
> 
>>
>> Luca
>>
> 

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

> On 20 Jan 2017, at 21:13, William A Rowe Jr  wrote:
> 
> On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr  
> wrote:
>> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>>  wrote:
>>> RFC 7231 has retired Content-MD5.
>>> 
>>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
>>> or INFO and retire it at the next minor release ?
> 
> +1
> 
>> Removing what, precisely? Content-MD5 headers aren't implemented in trunk.
> 
> Sorry, I missed a -i arg to grep :)
> 
Ah ok - thanks - I was wondering I had been in Amsterdam for too long (which I 
had - and it involved shops where they do sell coffee).

> Yes, the default_handler behavior in trunk/server/core.c can simply be 
> removed,
> along with the core.c ContentDigest directive handling. I think it
> should also be
> removed from modules/cache/mod_cache.c as it is not a valid entity header.
> 
> The many unset Content-MD5 actions must remain IMO to guard against our
> sharing this upstream or downstream.
> 
> The http_core.h core flag content_md5 and values AP_CONTENT_MD5_*
> should probably remain until 3.0 to avoid unnecessary API changes. a doxygen
> /** @deprecated Unused flag */ against that struct member will help us mop 
> these
> up during any 3.0 review.

Dw.

Re: svn commit: r1779525 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

[Jim Jagielski]

> On Jan 19, 2017, at 4:00 PM, Ruediger Pluem  wrote:
> 
> 
> 
> On 01/19/2017 09:38 PM, ic...@apache.org wrote:
>> Author: icing
>> Date: Thu Jan 19 20:38:50 2017
>> New Revision: 1779525
>> 
>> URL: http://svn.apache.org/viewvc?rev=1779525=rev
>> Log:
>> On the trunk:
>> 
>> mod_http2: decoupling lifetime of mplx pool from h2_session which messed up 
>> the cleanup ordering.
>> 
>> 
>> Modified:
>>httpd/httpd/trunk/modules/http2/h2_mplx.c
>> 
>> Modified: httpd/httpd/trunk/modules/http2/h2_mplx.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1779525=1779524=1779525=diff
>> ==
>> --- httpd/httpd/trunk/modules/http2/h2_mplx.c (original)
>> +++ httpd/httpd/trunk/modules/http2/h2_mplx.c Thu Jan 19 20:38:50 2017
>> @@ -280,7 +280,7 @@ h2_mplx *h2_mplx_create(conn_rec *c, apr
>> m->id = c->id;
>> APR_RING_ELEM_INIT(m, link);
>> m->c = c;
>> -apr_pool_create_ex(>pool, parent, NULL, allocator);
>> +apr_pool_create_ex(>pool, NULL, NULL, allocator);
> 
> Without further investigations: Global pools always make me worry. Are you 
> sure we don't introduce
> a memory leak here?
> 

Especially untagged ones!

Re: rfc7231 - content-md5

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr  wrote:
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>  wrote:
>> RFC 7231 has retired Content-MD5.
>>
>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN 
>> or INFO and retire it at the next minor release ?

+1

> Removing what, precisely? Content-MD5 headers aren't implemented in trunk.

Sorry, I missed a -i arg to grep :)

Yes, the default_handler behavior in trunk/server/core.c can simply be removed,
along with the core.c ContentDigest directive handling. I think it
should also be
removed from modules/cache/mod_cache.c as it is not a valid entity header.

The many unset Content-MD5 actions must remain IMO to guard against our
sharing this upstream or downstream.

The http_core.h core flag content_md5 and values AP_CONTENT_MD5_*
should probably remain until 3.0 to avoid unnecessary API changes. a doxygen
/** @deprecated Unused flag */ against that struct member will help us mop these
up during any 3.0 review.

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Graham Leggett]

On 20 Jan 2017, at 7:47 PM, David Zuelke  wrote:

> I'd actually like to question the whole practice of porting features back to 
> older branches. I think that's the core reason why trunk is in total 
> disarray, and why no substantial releases have been made. There is just no 
> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
> just backport whatever you want.

The reason this is bad is because Apache httpd comes with a module ecosystem - 
when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the 
ABI can break, and therefore all modules that depend on that version must be 
recompiled. This includes modules that are closed source and offered by a 
proprietary vendor, or are open source but provided in binary form by a distro.

Right now, you can get new features on the httpd v2.4 branch, but ONLY if that 
feature does not break existing behaviour in any way. This is entirely 
reasonable, convenient, and what we’ve been doing since the 1990s.

> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the 
> process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? 
> It's already "stable". It doesn't need more features that suddenly change 
> behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users 
> are looking for).
> 
> That's how PHP does it now... new features can go into x.y.0, and once that 
> is released (actually, once it's in beta stage), anything that is not a small 
> fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because 
> these releases land every year now, like clockwork.

So you have to wait a year for new features to see a release? Definitely not 
keen on that.

> I have said this in the other thread that hasn't gotten much traction ("A new 
> release process?"). The PHP team was in the exact same spot as HTTPD a few 
> years ago. No substantial progress, stale branches, no light at the end of 
> the tunnel, and a lot of fighting.

We’ve had a significant amount of progress, a trunk that is so stable that 
almost all fixes and features can be backported to v2.4 without any fear of 
incompatibility, and the “fighting” is limited to very few individuals.

We’re not broken, we don’t need fixing.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: rfc7231 - content-md5

[Dirk-Willem van Gulik]

On 20 Jan 2017, at 20:49, William A Rowe Jr  wrote:
> 
> Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
> for MD5 hashed
> digest auth keys. So removing this altogether will break mod_auth_digest in a
> manner that breaks existing user auth.
> 

> 
> Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
> for MD5 hashed
> digest auth keys. So removing this altogether will break mod_auth_digest in a
> manner that breaks existing user auth.

Right - and these need to stay. These are for interoperability reasons - and 
only affect that.

I think I am getting somewhere - currently going to a handful of packages that 
use ARP
and splitting things into:

apr_digest_64()
apr_digest_128()
apr_digest_256()
apr_digest_512()

for places where the is no cryptographic need and

apr_crypto_digest  ---

with the actual name of a cryptographic algorithm like SHA256, etc. Either 
because
it has a cryptographic need -or- because of interoperability -or- both.

And that seems to yield fairly clean results - which ultimately are conductive 
to
'fips' style flags to 'force' ancient algorithms, like MD5, to be not in 
critical places;
while letting harmless continue.

Dw

Re: svn commit: r1779525 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

[Stefan Eissing]

> Am 20.01.2017 um 21:59 schrieb Jim Jagielski :
> 
> 
>> On Jan 19, 2017, at 4:00 PM, Ruediger Pluem  wrote:
>> 
>> 
>> 
>> On 01/19/2017 09:38 PM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Thu Jan 19 20:38:50 2017
>>> New Revision: 1779525
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1779525=rev
>>> Log:
>>> On the trunk:
>>> 
>>> mod_http2: decoupling lifetime of mplx pool from h2_session which messed up 
>>> the cleanup ordering.
>>> 
>>> 
>>> Modified:
>>>   httpd/httpd/trunk/modules/http2/h2_mplx.c
>>> 
>>> Modified: httpd/httpd/trunk/modules/http2/h2_mplx.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1779525=1779524=1779525=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/http2/h2_mplx.c (original)
>>> +++ httpd/httpd/trunk/modules/http2/h2_mplx.c Thu Jan 19 20:38:50 2017
>>> @@ -280,7 +280,7 @@ h2_mplx *h2_mplx_create(conn_rec *c, apr
>>>m->id = c->id;
>>>APR_RING_ELEM_INIT(m, link);
>>>m->c = c;
>>> -apr_pool_create_ex(>pool, parent, NULL, allocator);
>>> +apr_pool_create_ex(>pool, NULL, NULL, allocator);
>> 
>> Without further investigations: Global pools always make me worry. Are you 
>> sure we don't introduce
>> a memory leak here?
>> 
> 
> Especially untagged ones!

Has already been reverted.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Graham Leggett]

On 20 Jan 2017, at 10:40 PM, Jim Jagielski  wrote:

> In fact, I'd announce 2.5-alpha "immediately" as what's
> in trunk... with a set schedule that 2.6-Beta1 is tagged 2
> months later and a goal that 2.6-GA be announced at
> ApacheCon Miami.
> 
> But this all implies that 2.5/2.6 not be the huge restructure/re-
> factor envisioned by some.

I’m keen to see v2.5-alpha out soon.

There will be a drive to ensure the new goodness on trunk is stable and fixed, 
and this is a good thing.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Ruediger Pluem]

On 01/20/2017 09:37 PM, Graham Leggett wrote:
> On 20 Jan 2017, at 7:47 PM, David Zuelke  wrote:
> 
>> I'd actually like to question the whole practice of porting features back to 
>> older branches. I think that's the core reason why trunk is in total 
>> disarray, and why no substantial releases have been made. There is just no 
>> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
>> just backport whatever you want.
> 
> The reason this is bad is because Apache httpd comes with a module ecosystem 
> - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that 
> the ABI can break, and therefore all modules that depend on that version must 
> be recompiled. This includes modules that are closed source and offered by a 
> proprietary vendor, or are open source but provided in binary form by a 
> distro.

I share this concern. If you put new features only in 2.current+1 then most 
users have to wait for years until they can
use them due to the lack of support by third parties for 2.current+1. You might 
argue if you speed up with increasing
x in 2.x and faster deprecating older 2.y you would solve that issue and 3rd 
parties would simply speed up their model.
But I don't think so. I think and some actually do they would create there own 
fork of 2.x and only supply the
modules for that fork leaving you locked in a closed vendor solution with 
"features" added by them. Nothing I am keen on.

> 
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if 
> that feature does not break existing behaviour in any way. This is entirely 
> reasonable, convenient, and what we’ve been doing since the 1990s.
> 
>> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start 
>> the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right 
>> now? It's already "stable". It doesn't need more features that suddenly 
>> change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of 
>> what users are looking for).
>>
>> That's how PHP does it now... new features can go into x.y.0, and once that 
>> is released (actually, once it's in beta stage), anything that is not a 
>> small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal 
>> because these releases land every year now, like clockwork.
> 
> So you have to wait a year for new features to see a release? Definitely not 
> keen on that.
> 
>> I have said this in the other thread that hasn't gotten much traction ("A 
>> new release process?"). The PHP team was in the exact same spot as HTTPD a 
>> few years ago. No substantial progress, stale branches, no light at the end 
>> of the tunnel, and a lot of fighting.
> 
> We’ve had a significant amount of progress, a trunk that is so stable that 
> almost all fixes and features can be backported to v2.4 without any fear of 
> incompatibility, and the “fighting” is limited to very few individuals.
> 
> We’re not broken, we don’t need fixing.

I wouldn't say we don't need fixing. But IMHO we don't need fixing in the way 
proposed.
We need to work on getting a better testing in place. Honestly I don't have an 
answer at hand how to do this,
but from my personal point of view I think that our perl framework is sometimes 
a little hard to work with
(might be my own limitation) and we lack the possibility of doing internal API 
tests more easily (I know that you can do
certain tests by creating C test modules in the perl framework, but that should 
be easier).
That would increase stability of our release and avoid regressions better.
But the cause for introducing regressions isn't because a feature is ported 
back, we have regressions as well on bug
fixes, the cause is in most cases the complexity of the code ported back or 
better the complexity of the code region
touched.
And by complexity in this case I don't mean necessarily the number of code 
lines ported back. A one line change can
cause ugly regressions if it messes with a complex subject.
But maybe that tells us that we need to restructure these areas of code to make 
them easier to understand and thus
more stable to changes.
Honestly the stuff above sounds like a lot of thankless work and not sexy and 
that maybe the reason why we lack progress
here.

Regards

Rüdiger

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Hi,

this patch solved the file_close segfault. Never saw that again.

Right now i got this one:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f129f612274 in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x7f129f612274 in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f129fe83bc9 in apr_thread_mutex_lock (mutex=)
at locks/unix/thread_mutex.c:92
#2  0x7f129fe82712 in apr_file_seek
(thefile=thefile@entry=0x7f120c0670c0, where=where@entry=0,
offset=offset@entry=0x7f12897f9b60) at file_io/unix/seek.c:62
#3  0x004dc413 in read_to_scratch (b=0x7f11c807ea08,
io=0x7f11c80806d8) at h2_conn_io.c:220
#4  h2_conn_io_pass (io=io@entry=0x7f11c80806d8, bb=0x7f11c8080a08) at
h2_conn_io.c:434
#5  0x004ca3ae in on_send_data_cb (ngh2=,
frame=, framehd=, length=1291,
source=, userp=0x7f11c8080690) at h2_session.c:649
#6  0x7f12a0980e95 in ?? () from
/usr/lib/x86_64-linux-gnu/libnghttp2.so.14
#7  0x7f12a0981ea9 in nghttp2_session_send () from
/usr/lib/x86_64-linux-gnu/libnghttp2.so.14
#8  0x004cca89 in h2_session_send (session=0x7f11c8080690) at
h2_session.c:1414
#9  0x004cfc8c in h2_session_process (session=0x7f11c8080690,
async=1) at h2_session.c:2246
#10 0x004bf641 in h2_conn_run (ctx=0x7f120c066730,
c=0x7f128c06cd98) at h2_conn.c:214
#11 0x004c202a in h2_h2_process_conn (c=0x3732323535395f39) at
h2_h2.c:658
#12 0x0046a450 in ap_run_process_connection (c=0x7f128c06cd98)
at connection.c:42
#13 0x004fbf10 in process_socket (my_thread_num=,
my_child_num=, cs=0x7f128c06cd08,
sock=, p=, thd=) at
event.c:1134
#14 worker_thread (thd=0x3732323535395f39, dummy=0x0) at event.c:2137
#15 0x7f129f6100a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#16 0x7f129f14162d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan

Am 20.01.2017 um 18:17 schrieb Yann Ylavic:
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
>  wrote:
>> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
>> pool. Not like before where i got many different ones.
> 
> Could you try this new patch on mod_http2 please?
> 
> Thanks,
> Yann.
> 

Re: svn commit: r1776575 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_remoteip.xml modules/metadata/mod_remoteip.c

[Christophe JAILLET]

First of all, http://blog.haproxy.com/haproxy/proxy-protocol/ list 
another module implementation for Apache:

https://github.com/ggrandes/apache24-modules/blob/master/mod_myfixip.c

If anyone wants to give it a look.



Anyway, a few minor comments below.

CJ


Le 30/12/2016 à 15:20, drugg...@apache.org a écrit :

Author: druggeri
Date: Fri Dec 30 14:20:48 2016
New Revision: 1776575

URL:http://svn.apache.org/viewvc?rev=1776575=rev
Log:
Merge new PROXY protocol code into mod_remoteip

Modified:
 httpd/httpd/trunk/docs/log-message-tags/next-number
 httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
 httpd/httpd/trunk/modules/metadata/mod_remoteip.c

Modified: httpd/httpd/trunk/docs/log-message-tags/next-number
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?rev=1776575=1776574=1776575=diff
==
--- httpd/httpd/trunk/docs/log-message-tags/next-number (original)
+++ httpd/httpd/trunk/docs/log-message-tags/next-number Fri Dec 30 14:20:48 2016
@@ -1 +1 @@
-3491
+3514

Modified: httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml?rev=1776575=1776574=1776575=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_remoteip.xml Fri Dec 30 14:20:48 2016
@@ -42,6 +42,12 @@ via the request headers.
  with the useragent IP address reported in the request header configured
  with the RemoteIPHeader 
directive.
  
+Additionally, this module implements the server side of

+HAProxy's
+http://blog.haproxy.com/haproxy/proxy-protocol/;>Proxy 
Protocol when
+using the RemoteIPProxyProtocolEnable
+directive.
+
  Once replaced as instructed, this overridden useragent IP address is
  then used for the mod_authz_host
  Require ip
@@ -59,6 +65,7 @@ via the request headers.
  mod_authz_host
  mod_status
  mod_log_config
+http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt;>Proxy 
Protocol Spec
  
  Remote IP Processing
  
@@ -214,6 +221,70 @@ RemoteIPProxiesHeader X-Forwarded-By

  
  
  
+

+RemoteIPProxyProtocol


s/RemoteIPProxyProtocol/RemoteIPProxyProtocolEnable/


+Enable, optionally enable or disable the proxy protocol 
handling
+ProxyProtocol On|Optional|Off
+server configvirtual host
+


Compatibility note missing.


+
+
+The RemoteIPProxyProtocolEnable enables or
+disables the reading and handling of the proxy protocol connection header.
+If enabled with the On flag, the upstream client must
+send the header every time it opens a connection or the connection will
+be aborted. If enabled with the Optional flag, the upstream
+client may send the header.
+
+While this directive may be specified in any virtual host, it is
+important to understand that because the proxy protocol is connection
+based and protocol agnostic, the enabling and disabling is actually based
+on ip-address and port. This means that if you have multiple name-based
+virtual hosts for the same host and port, and you enable it any one of
+them, then it is enabled for all them (with that host and port). It also
+means that if you attempt to enable the proxy protocol in one and disable
+in the other, that won't work; in such a case the last one wins and a
+notice will be logged indicating which setting was being overridden.
+
+When multiple virtual hosts on the same IP and port are
+configured with a combination of On and Optional
+flags, connections will not be aborted if the header is not sent.
+Instead, enforcement will happen after the request is read so virtual
+hosts configured with On will return a 400 Bad Request.
+Virtual hosts configured with Optional will continue as
+usual but without replacing the client IP information
+
+
+Listen 80
+VirtualHost *:80
+ServerNamewww.example.com
+RemoteIPProxyProtocolEnable Optional
+
+#Requests to this virtual host may optionally not have
+# a proxy protocol header provided
+/VirtualHost
+
+VirtualHost *:80
+ServerNamewww.example.com
+RemoteIPProxyProtocolEnable On
+
+#Requests to this virtual host must have a proxy protocol
+# header provided. If it is missing, a 400 will result
+/VirtualHost
+
+Listen 8080
+VirtualHost *:8080
+ServerNamewww.example.com
+RemoteIPProxyProtocolEnable On
+
+#Requests to this virtual host must have a proxy protocol
+# header provided. If it is missing, the connection will
+# be aborted
+/VirtualHost
+
+
+
+
  
  RemoteIPTrustedProxy
  Restrict client IP addresses trusted to present the RemoteIPHeader 
value

Modified: httpd/httpd/trunk/modules/metadata/mod_remoteip.c

Re: Alternate versioning proposal: patch line releases

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 8:07 AM, Graham Leggett  wrote:
> On 20 Jan 2017, at 2:15 AM, Jacob Champion  wrote:
>
>> Ignore the versioning number then; that's not really the core of my 
>> proposal. The key points I'm making are
>>
>> - introduce the concept of a low-risk release line
>
> We have always had this, the current low-risk release line is called v2.4.x.
>
>> - introduce a stable cadence with as little risk to end users as possible
>
> We have always had this.

Many if not most developers disagree with you, most developers agree that
adding features and enhancements is disruptive. 2.4.x adds features and
enhancements to every release, and is therefore not low-risk, and absolutely
not "as little risk as possible".

C.f. para 4; 
https://en.wikipedia.org/wiki/Software_versioning#Change_significance

Re: Alternate versioning proposal: patch line releases

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 5:49 PM, Jacob Champion  wrote:
> This is somewhat orthogonal to Bill's current suggestion. It solves a
> different set of problems, more related to the short-term
> features-versus-regressions argument and less related to the long-term ABI
> arguments. Both are important to me, and I agree with many pieces of what
> both Jim and Bill are saying.
>
> (This is a combination of a bunch of different ideas from different people,
> on this list and off, so thank you all for discussing.)
>
> == Proposal ==
>
> 2.4.25.x is on a cadence: it's T'd like clockwork every month. Releases
> from that line still follow the necessary voting procedure. Meanwhile, once
> we decide we have enough new features for 2.4.26, we T that. If 2.4.26
> releases, and we decide we need some fixes, we spin up a 2.4.26.x branch and
> move to a cadence on it.

This is the OpenSSL model which httpd effectively mirrors today, although
their .x is an alpha sequence, and your proposal could be read with either
semantic.

However, OpenSSL changes very little in terms of it's scope, and isn't the
best model for an evolutionary, development driven project like httpd.

1.0.0 and 1.1.0 both refactored much of the API in terms of opacity of internal
data members.

1.0.0, 1.0.1, 1.0.2 were incremental TLS features, but as these were defined
by spec, the scope of those upgrades was clear.

So I'd anticipate 1.1.1 if the API is extended further for new TLS features
without other changes, or I'd anticipate 1.2.0 if the API will be further
refactored (or both.)

But given the amount of recoding required to migrate from 1.0.x -> 1.1.0,
as illustrated by a bunch of patches here for mod_ssl, most modern
developers would have considered that rework a 2.0 scope change.

At least the OpenSSL project accomplishes what you outlined above,
irrespective of their number-alpha'ing schema.

Re: Alternate versioning proposal: patch line releases

[Eric Covener]

On Fri, Jan 20, 2017 at 9:53 AM, William A Rowe Jr  wrote:
> Many if not most developers disagree with you, most developers agree that
> adding features and enhancements is disruptive. 2.4.x adds features and
> enhancements to every release, and is therefore not low-risk, and absolutely
> not "as little risk as possible".

Maybe a [POLL] thread is in order, specifically for the topic of
enhancements/stability in 2.4 and ignoring aspirations about a new
versioning system or 3.0.

e.g.

2.4.x is:
 [ ] evolving just fine
 [ ] too unstable due to new features and we need to do something about it.
 [ ] too unstable due to code/review/test escapes and we need to do
something about it.


-- 
Eric Covener
cove...@gmail.com

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Hi,

it crashed again with V6 and plain mod_http2 v1.8.8.

This is the crash incl. line numbers:
Program terminated with signal SIGSEGV, Segmentation fault.
#0  apr_pool_cleanup_kill (p=0x2d392d322d32,
data=data@entry=0x7f330006bc70,
cleanup_fn=cleanup_fn@entry=0x7f33155b0f90 )
at memory/unix/apr_pools.c:2264
2264memory/unix/apr_pools.c: No such file or directory.
(gdb) bt
#0  apr_pool_cleanup_kill (p=0x2d392d322d32,
data=data@entry=0x7f330006bc70,
cleanup_fn=cleanup_fn@entry=0x7f33155b0f90 )
at memory/unix/apr_pools.c:2264
#1  0x7f33155b5e51 in apr_pool_cleanup_run (p=,
data=0x7f330006bc70,
cleanup_fn=0x7f33155b0f90 ) at
memory/unix/apr_pools.c:2342
#2  0x7f33155b1322 in apr_file_close (file=) at
file_io/unix/open.c:255
#3  0x004d0012 in stream_pool_cleanup (ctx=0x7f3294022480) at
h2_stream.c:182
#4  0x7f33155b4b1e in run_cleanups (cref=) at
memory/unix/apr_pools.c:2352
#5  apr_pool_destroy (pool=0x7f3294022408) at memory/unix/apr_pools.c:814
#6  0x004d0786 in h2_stream_destroy (stream=) at
h2_stream.c:249
#7  0x004c334c in stream_done (m=,
stream=, rst_error=) at h2_mplx.c:470
#8  0x004c335b in stream_done_iter (ctx=,
val=) at h2_mplx.c:475
#9  0x7f33155ac156 in apr_hash_do (comp=comp@entry=0x4d5880
, rec=rec@entry=0x7f32f7feea50, ht=)
at tables/apr_hash.c:542
#10 0x004d623d in h2_ihash_iter (ih=,
fn=fn@entry=0x4c3350 , ctx=ctx@entry=0x7f3294034c88)
at h2_util.c:315
#11 0x004c4649 in h2_mplx_release_and_join (m=0x7f3294034c88,
wait=0x7f3294034c30) at h2_mplx.c:579
#12 0x004ca7cf in h2_session_destroy (session=0x7f3294034a50) at
h2_session.c:739
#13 0x0045b726 in remove_empty_buckets (bb=0x7f330006af18) at
core_filters.c:720
#14 0x0045be28 in setaside_remaining_output (f=0x7f32ec0c5b88,
ctx=0x7f32ec0c5e48, bb=0x7f330006af18, c=,
c=) at core_filters.c:584
#15 0x0045c896 in ap_core_output_filter (f=0x2d392d322d32,
new_bb=0x7f330006af18) at core_filters.c:568
#16 0x004ad932 in ssl_io_filter_output (f=0x7f330006aed0,
bb=0x7f32ec0c5f10) at ssl_engine_io.c:1716
#17 0x004aad0a in ssl_io_filter_coalesce (f=0x2d392d322d32,
bb=0x7f32ec0c5f10) at ssl_engine_io.c:1663
#18 0x004db543 in pass_output (io=0x7f3294034a98,
session_eoc=0x7f3294034a50, flush=) at h2_conn_io.c:311
#19 0x004cf50a in h2_session_process (session=0x7f3294034a50,
async=1) at h2_session.c:2347
#20 0x004befb2 in h2_conn_run (ctx=0x7f32ec0c5e18,
c=0x7f330006a958) at h2_conn.c:214
#21 0x004c198a in h2_h2_process_conn (c=0x2d392d322d32) at
h2_h2.c:658
#22 0x0046a2b0 in ap_run_process_connection (c=0x7f330006a958)
at connection.c:42
#23 0x004fb890 in process_socket (my_thread_num=,
my_child_num=, cs=0x7f330006a8c8,
sock=, p=, thd=) at
event.c:1134
#24 worker_thread (thd=0x2d392d322d32, dummy=0x7f330006bc70) at
event.c:2137
#25 0x7f3314d400a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#26 0x7f331487162d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan
Am 20.01.2017 um 13:20 schrieb Stefan Eissing:
> Please without. Then I least know if that version behaves. Planning on more 
> extensive changes for a 1.9.0 now. Thanks!
> 
> -Stefan
> 
>> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without 
>> patches?
>>
>> Greets,
>> Stefan
>>
>> Excuse my typo sent from my mobile phone.
>>
>> Am 20.01.2017 um 13:04 schrieb Stefan Eissing :
>>
>>> Different apr versions? Might there have been a bugfix affecting us?
>>>
 Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
 :

 might this be a debian bug? i can't reproduce with apr-included.

 Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
> Hi,
>
> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>  wrote:
>> Hi Stefan,
>>
>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
>>> this seems to be a tough bone to chew. Therefore we need to go deeper:
>>> - can you compile the module so that we see line numbers in the trace?
>>
>> Do you have any idea how to arrange this? I've no idea how to pass the
>> -ggdb option through Apache.
>
> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
>
>>
>>> - which apr version are you using?
>> this one:
>> https://packages.debian.org/jessie/libapr1
>
> Could you also build libapr1 with this same flags?
>
>>>
>>> Stefan Eissing
>>>
>>> bytes GmbH
>>> Hafenstrasse 16
>>> 48155 Münster
>>> www.greenbytes.de
>>>
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Re: svn commit: r1779578 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml

[Luca Toscano]

2017-01-20 10:45 GMT+01:00 Stefan Eissing :

>
> > Am 20.01.2017 um 10:35 schrieb Luca Toscano :
> >
> >
> >
> > 2017-01-20 10:11 GMT+01:00 ste...@eissing.org :
> >
> > > Am 20.01.2017 um 09:45 schrieb elu...@apache.org:
> > >
> > > Author: elukey
> > > Date: Fri Jan 20 08:45:40 2017
> > > New Revision: 1779578
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1779578=rev
> > > Log:
> > > Added more details to mod-proxy-http2's doc
> > >
> > > Modified:
> > >httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > >
> > > Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/
> mod/mod_proxy_http2.xml?rev=1779578=1779577=1779578=diff
> > > 
> ==
> > > --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml (original)
> > > +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml Fri Jan 20
> 08:45:40 2017
> > > @@ -41,9 +41,14 @@
> > > have to be present in the server.
> > >
> > > mod_proxy_http2 works with incoming requests
> > > -over HTTP/1.1 and HTTP/2 requests. If mod_http2
> > > -handles the frontend connection, requests against the same HTTP/2
> > > -backend are sent over a single connection, whenever possible.
> > > +over HTTP/1.1 and HTTP/2 requests. In both cases, requests proxied
> > > +to the same backend are sent over a single connection
> > > +whenever possible (namely when the connection can be re-used).
> > > +
> > > +mod_proxy_http2 will not use the HTTP/2
> protocol
> > > +when the frontend requests use HTTP/1.1.
> > > +This means that HTTP/2 will be used to proxy requests to a
> capable backend
> > > +only when the frontend requests use the same protocol.
> > >
> >
> > Not correct. Maybe my explanation was not good. mod_proxy_http2 will
> always use HTTP/2 in the backend connection. That connection will however
> only do one request at a time if the frontend is HTTP/1.1.
> >
> > No no it is me being slow to understand HTTP/2 related things :)
> >
> > So mod-proxy-http2 will always use HTTP/2 with a "capable" backend, but
> it will not exploit its full potential when the frontend requests are
> HTTP/1.1 (for example "translating" multiple proxied HTTP/1.1 requests into
> HTTP/2 streams over the same TCP connection).
> >
> > Better? If not I can revert everything and leave you do it, might be
> better :)
>
> Nonono. No easy way out: :)
>
> You got it right, except one tiny detail: the backend *needs* to talk
> HTTP/2, there is no fallback to HTTP/1.1 by mod_proxy_http2. Which might be
> a feature for the future, or a folding of http/2 support into
> mod_proxy_http (far future).
>
>
So the info was there but my brain for some reason didn't pick it up :)

I reworded the documentation in http://svn.apache.org/r1779609, hope that
it is better this time!

Luca

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Eissing]

Different apr versions? Might there have been a bugfix affecting us?

> Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
> :
> 
> might this be a debian bug? i can't reproduce with apr-included.
> 
> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
>> Hi,
>> 
>> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>>  wrote:
>>> Hi Stefan,
>>> 
>>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
 this seems to be a tough bone to chew. Therefore we need to go deeper:
 - can you compile the module so that we see line numbers in the trace?
>>> 
>>> Do you have any idea how to arrange this? I've no idea how to pass the
>>> -ggdb option through Apache.
>> 
>> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
>> 
>>> 
 - which apr version are you using?
>>> this one:
>>> https://packages.debian.org/jessie/libapr1
>> 
>> Could you also build libapr1 with this same flags?
>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Eissing]

Please without. Then I least know if that version behaves. Planning on more 
extensive changes for a 1.9.0 now. Thanks!

-Stefan

> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without 
> patches?
> 
> Greets,
> Stefan
> 
> Excuse my typo sent from my mobile phone.
> 
> Am 20.01.2017 um 13:04 schrieb Stefan Eissing :
> 
>> Different apr versions? Might there have been a bugfix affecting us?
>> 
>>> Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> might this be a debian bug? i can't reproduce with apr-included.
>>> 
>>> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
 Hi,
 
 On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
  wrote:
> Hi Stefan,
> 
> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
>> this seems to be a tough bone to chew. Therefore we need to go deeper:
>> - can you compile the module so that we see line numbers in the trace?
> 
> Do you have any idea how to arrange this? I've no idea how to pass the
> -ggdb option through Apache.
 
 DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
 
> 
>> - which apr version are you using?
> this one:
> https://packages.debian.org/jessie/libapr1
 
 Could you also build libapr1 with this same flags?
 
>> 
>> Stefan Eissing
>> 
>> bytes GmbH
>> Hafenstrasse 16
>> 48155 Münster
>> www.greenbytes.de
>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: mod_http2 and Frequent wake-ups for mpm_event

[Yann Ylavic]

On Fri, Jan 20, 2017 at 12:49 PM, Stefan Priebe - Profihost AG
 wrote:
> might this be a debian bug? i can't reproduce with apr-included.

Did you build the included-apr (and httpd) with -fno-strict-aliasing ?
Not sure Debian sets it for its builds either, just a speculation (I
used to have issues in APR_RING without it).

Re: mod_http2 and Frequent wake-ups for mpm_event

[Yann Ylavic]

Please use V7 too, I don't think I'll revert it in trunk (it makes sense).

On Fri, Jan 20, 2017 at 1:20 PM, Stefan Eissing
 wrote:
> Please without. Then I least know if that version behaves. Planning on more 
> extensive changes for a 1.9.0 now. Thanks!
>
> -Stefan
>
>> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without 
>> patches?
>>
>> Greets,
>> Stefan
>>
>> Excuse my typo sent from my mobile phone.
>>
>> Am 20.01.2017 um 13:04 schrieb Stefan Eissing :
>>
>>> Different apr versions? Might there have been a bugfix affecting us?
>>>
 Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
 :

 might this be a debian bug? i can't reproduce with apr-included.

 Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
> Hi,
>
> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>  wrote:
>> Hi Stefan,
>>
>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
>>> this seems to be a tough bone to chew. Therefore we need to go deeper:
>>> - can you compile the module so that we see line numbers in the trace?
>>
>> Do you have any idea how to arrange this? I've no idea how to pass the
>> -ggdb option through Apache.
>
> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
>
>>
>>> - which apr version are you using?
>> this one:
>> https://packages.debian.org/jessie/libapr1
>
> Could you also build libapr1 with this same flags?
>
>>>
>>> Stefan Eissing
>>>
>>> bytes GmbH
>>> Hafenstrasse 16
>>> 48155 Münster
>>> www.greenbytes.de
>>>
>
> Stefan Eissing
>
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
>

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Graham Leggett]

On 19 Jan 2017, at 11:43 PM, William A Rowe Jr  wrote:

> I think one of our disconnects with 2.4 -> 2.6 is that in any other
> framework, there would be no ABI breakage in 2.6. That breakage
> would be deferred to and shipped as 3.0.
> 
> The httpd project choose to call 2.minor releases as breaking
> changes. Due to poor design choices, or frequent refactorings,
> this essentially shifted our release numbering schema down one
> digit. So 2.6.0 is not an enhancement release, but a major release
> in the general understanding of these things. This might be the root
> of Jim's and my failure to come to any consensus.

I don’t see any relationship between poor design choices / frequent 
refactorings and a decision made in the late 1990s on a version numbering 
system.

> Right now, there are a number of gratuitous breaking changes on trunk
> that change binary ABI. I'm considering a trunk fork to preserve these
> changes (branches/3.x-future/?) and reverting every change to trunk/
> which was otherwise a no-op. Namespace, decoration, anything that
> prevents a user from loading a 2.4.x module in 2.next. And then we
> can look at what is a valid reason to take us to 3.0.

-1 (veto).

As you are well aware, the jump from v2.0 to v2.2, from v2.2 to v2.4, and the 
jump from v2.4 to v2.6 involves breaking changes, and this is a well 
established and stable pattern that is well understood by our end users. The 
“problem” you’re trying to solve does not exist.

Arbitrarily reverting the work of others displays a profound lack of respect 
for those members, committers and contributors to the ASF who have contributed 
to our codebase. This behaviour discourages collaboration between the community 
and project, and puts this project at risk.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: mod_http2 and Frequent wake-ups for mpm_event

[Yann Ylavic]

On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
 wrote:
> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
> pool. Not like before where i got many different ones.

Could you try this new patch on mod_http2 please?

Thanks,
Yann.
Index: modules/http2/h2_stream.c
===
--- modules/http2/h2_stream.c	(revision 1778313)
+++ modules/http2/h2_stream.c	(working copy)
@@ -171,21 +171,20 @@ static void prepend_response(h2_stream *stream, h2
 static apr_status_t stream_pool_cleanup(void *ctx)
 {
 h2_stream *stream = ctx;
-apr_status_t status;
 
 ap_assert(stream->can_be_cleaned);
-if (stream->files) {
+/* Files are cleaned-up/closed already, just log */
+if (APLOGctrace3(stream->session->c) && stream->files) {
 apr_file_t *file;
 int i;
 for (i = 0; i < stream->files->nelts; ++i) {
 file = APR_ARRAY_IDX(stream->files, i, apr_file_t*);
-status = apr_file_close(file);
 ap_log_cerror(APLOG_MARK, APLOG_TRACE3, status, stream->session->c, 
   "h2_stream(%ld-%d): destroy, closed file %d", 
   stream->session->id, stream->id, i);
 }
-stream->files = NULL;
 }
+stream->files = NULL;
 return APR_SUCCESS;
 }
 

Re: Alternate versioning proposal: patch line releases

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener  wrote:
>
> Maybe a [POLL] thread is in order, specifically for the topic of
> enhancements/stability in 2.4 and ignoring aspirations about a new
> versioning system or 3.0.
>
> e.g.
>
> 2.4.x is:
>  [ ] evolving just fine
>  [ ] too unstable due to new features and we need to do something about it.
>  [ ] too unstable due to code/review/test escapes and we need to do
> something about it.

Perhaps too many choices?

One possible poll;

New features/enhancements;
[ ] belong on 2.4.x
[ ] should be released as 2.5.0

An entirely different possible poll;

[Multiple Choice - pick two(?) top issues] Apache HTTP Server is lacking in
[ ] new features and enhancements
[ ] code quality
[ ] code review
[ ] test scripts
[ ] contributors
[ ] documentation
[ ] cooperation

Cross pollinating a poll with multiple a/b decision points (is it good/bad,
should we solve x/y) dilutes the chance to work out root causes and
to work out potential solutions. "Do something about it" is a particularly
silly question, since committers will focus on what they want to focus
on, there is no ASF script for "tell people what to work on."

And of course, a new thread Subject: to whatever poll someone wants
to run. I don't plan to submit a poll, I'm just working from all individuals'
responses to these several threads to determine where we sit on the
whole spectrum of rapid updates vs version stability, to base any formal
proposal and [vote] later on. I particularly don't care where 2.4.x goes,
I'm more interested in agreeing to a process and moving on.

Re: Alternate versioning proposal: patch line releases

[Yann Ylavic]

On Fri, Jan 20, 2017 at 5:27 PM, William A Rowe Jr  wrote:
> On Fri, Jan 20, 2017 at 9:43 AM, Eric Covener  wrote:
>>
>> Maybe a [POLL] thread is in order, specifically for the topic of
>> enhancements/stability in 2.4 and ignoring aspirations about a new
>> versioning system or 3.0.
>>
>> e.g.
>>
>> 2.4.x is:
>>  [ ] evolving just fine
>>  [ ] too unstable due to new features and we need to do something about it.
>>  [ ] too unstable due to code/review/test escapes and we need to do
>> something about it.

I wouldn't how to vote with this one, "evolving not as fast as I'd
like" and "quite stable" is my opinion...

>
>
> One possible poll;
>
> New features/enhancements;
> [ ] belong on 2.4.x
> [ ] should be released as 2.5.0

I like this one, for now :)
(nothing better to propose...)

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Yes. Until now I got 4 traces. But all are the same pointing to apr kill pool. 
Not like before where i got many different ones.

Greets,
Stefan

Excuse my typo sent from my mobile phone.

> Am 20.01.2017 um 17:44 schrieb Yann Ylavic :
> 
> On Fri, Jan 20, 2017 at 5:41 PM, Stefan Priebe - Profihost AG
>  wrote:
>> Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.
> 
> Unpatched but still compiled with -fno-strict-aliasing (along with APR)?
> 
> Thanks,
> Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

[Yann Ylavic]

On Fri, Jan 20, 2017 at 5:41 PM, Stefan Priebe - Profihost AG
 wrote:
> Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.

Unpatched but still compiled with -fno-strict-aliasing (along with APR)?

Thanks,
Yann.

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.

Stefan

Excuse my typo sent from my mobile phone.

> Am 20.01.2017 um 16:23 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi,
> 
> it crashed again with V6 and plain mod_http2 v1.8.8.
> 
> This is the crash incl. line numbers:
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  apr_pool_cleanup_kill (p=0x2d392d322d32,
> data=data@entry=0x7f330006bc70,
>cleanup_fn=cleanup_fn@entry=0x7f33155b0f90 )
> at memory/unix/apr_pools.c:2264
> 2264memory/unix/apr_pools.c: No such file or directory.
> (gdb) bt
> #0  apr_pool_cleanup_kill (p=0x2d392d322d32,
> data=data@entry=0x7f330006bc70,
>cleanup_fn=cleanup_fn@entry=0x7f33155b0f90 )
> at memory/unix/apr_pools.c:2264
> #1  0x7f33155b5e51 in apr_pool_cleanup_run (p=,
> data=0x7f330006bc70,
>cleanup_fn=0x7f33155b0f90 ) at
> memory/unix/apr_pools.c:2342
> #2  0x7f33155b1322 in apr_file_close (file=) at
> file_io/unix/open.c:255
> #3  0x004d0012 in stream_pool_cleanup (ctx=0x7f3294022480) at
> h2_stream.c:182
> #4  0x7f33155b4b1e in run_cleanups (cref=) at
> memory/unix/apr_pools.c:2352
> #5  apr_pool_destroy (pool=0x7f3294022408) at memory/unix/apr_pools.c:814
> #6  0x004d0786 in h2_stream_destroy (stream=) at
> h2_stream.c:249
> #7  0x004c334c in stream_done (m=,
> stream=, rst_error=) at h2_mplx.c:470
> #8  0x004c335b in stream_done_iter (ctx=,
> val=) at h2_mplx.c:475
> #9  0x7f33155ac156 in apr_hash_do (comp=comp@entry=0x4d5880
> , rec=rec@entry=0x7f32f7feea50, ht=)
>at tables/apr_hash.c:542
> #10 0x004d623d in h2_ihash_iter (ih=,
> fn=fn@entry=0x4c3350 , ctx=ctx@entry=0x7f3294034c88)
>at h2_util.c:315
> #11 0x004c4649 in h2_mplx_release_and_join (m=0x7f3294034c88,
> wait=0x7f3294034c30) at h2_mplx.c:579
> #12 0x004ca7cf in h2_session_destroy (session=0x7f3294034a50) at
> h2_session.c:739
> #13 0x0045b726 in remove_empty_buckets (bb=0x7f330006af18) at
> core_filters.c:720
> #14 0x0045be28 in setaside_remaining_output (f=0x7f32ec0c5b88,
> ctx=0x7f32ec0c5e48, bb=0x7f330006af18, c=,
>c=) at core_filters.c:584
> #15 0x0045c896 in ap_core_output_filter (f=0x2d392d322d32,
> new_bb=0x7f330006af18) at core_filters.c:568
> #16 0x004ad932 in ssl_io_filter_output (f=0x7f330006aed0,
> bb=0x7f32ec0c5f10) at ssl_engine_io.c:1716
> #17 0x004aad0a in ssl_io_filter_coalesce (f=0x2d392d322d32,
> bb=0x7f32ec0c5f10) at ssl_engine_io.c:1663
> #18 0x004db543 in pass_output (io=0x7f3294034a98,
> session_eoc=0x7f3294034a50, flush=) at h2_conn_io.c:311
> #19 0x004cf50a in h2_session_process (session=0x7f3294034a50,
> async=1) at h2_session.c:2347
> #20 0x004befb2 in h2_conn_run (ctx=0x7f32ec0c5e18,
> c=0x7f330006a958) at h2_conn.c:214
> #21 0x004c198a in h2_h2_process_conn (c=0x2d392d322d32) at
> h2_h2.c:658
> #22 0x0046a2b0 in ap_run_process_connection (c=0x7f330006a958)
> at connection.c:42
> #23 0x004fb890 in process_socket (my_thread_num=,
> my_child_num=, cs=0x7f330006a8c8,
>sock=, p=, thd=) at
> event.c:1134
> #24 worker_thread (thd=0x2d392d322d32, dummy=0x7f330006bc70) at
> event.c:2137
> #25 0x7f3314d400a4 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #26 0x7f331487162d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Stefan
>> Am 20.01.2017 um 13:20 schrieb Stefan Eissing:
>> Please without. Then I least know if that version behaves. Planning on more 
>> extensive changes for a 1.9.0 now. Thanks!
>> 
>> -Stefan
>> 
>>> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without 
>>> patches?
>>> 
>>> Greets,
>>> Stefan
>>> 
>>> Excuse my typo sent from my mobile phone.
>>> 
 Am 20.01.2017 um 13:04 schrieb Stefan Eissing 
 :
 
 Different apr versions? Might there have been a bugfix affecting us?
 
> Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG 
> :
> 
> might this be a debian bug? i can't reproduce with apr-included.
> 
>> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
>> Hi,
>> 
>> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
>>  wrote:
>>> Hi Stefan,
>>> 
 Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
 this seems to be a tough bone to chew. Therefore we need to go deeper:
 - can you compile the module so that we see line numbers in the trace?
>>> 
>>> Do you have any idea how to arrange this? I've no idea how to pass the
>>> -ggdb option through Apache.
>> 
>> DEB_CFLAGS_SET="-O2 -ggdb -fno-strict-aliasing ..." dpkg-buildpackage ...
>> 
>>> 
 - which apr version are you using?
>>> this one:

Re: Reset out x.minor.z definition of 'minor' at httpd?

[David Zuelke]

> On 20.01.2017, at 15:34, William A Rowe Jr  wrote:
> 
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke  wrote:
>> I don't know any framework/language/library out there that handles it that 
>> strictly. Nginx, or Ruby, or PHP, or whatever...
>> 
>> From x.y.z to x.y.z+1, retain full compatibility.
>> 
>> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, 
>> break internal API if absolutely needed
>> 
>> From x.y.z to x+1.0.0, break anything you want.
>> 
>> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, 
>> and some of these are features, while other are big architectural overhauls. 
>> The former are for 2.6, and the latter very clearly belong into 3.0. There's 
>> no reason why both can't be worked on concurrently.
> 
> That's what I'm proposing... a model where x.y.[0-#] releases remain 
> consistent,
> like all the packages you mention above, and unlike httpd.
> 
> I liked your highlight of "if [absolutely] needed". That's where our
> trunk (2.next)
> has spent four years diverging from 2.current, mostly unnecessarily.
> 
> The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
> examples, such backports aren't even acceptable) means that it *could* have
> stayed consistent on our 2.next trunk.

I'd actually like to question the whole practice of porting features back to 
older branches. I think that's the core reason why trunk is in total disarray, 
and why no substantial releases have been made. There is just no reason for 
anyone to push forward the state of 2.6 or even 3.0 if you can just backport 
whatever you want.

Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the 
process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? 
It's already "stable". It doesn't need more features that suddenly change 
behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users 
are looking for).

That's how PHP does it now... new features can go into x.y.0, and once that is 
released (actually, once it's in beta stage), anything that is not a small fix 
needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these 
releases land every year now, like clockwork.

I have said this in the other thread that hasn't gotten much traction ("A new 
release process?"). The PHP team was in the exact same spot as HTTPD a few 
years ago. No substantial progress, stale branches, no light at the end of the 
tunnel, and a lot of fighting.

A structured release process fixed all that.

David

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Eissing]

Good catch, Yann.

I have local modifications that throw most of the manual cleanup out and rely 
on auto pool cleanup as much as possible. Curious if that will solve Stefan's 
crashes.


> Am 20.01.2017 um 18:17 schrieb Yann Ylavic :
> 
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
>  wrote:
>> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
>> pool. Not like before where i got many different ones.
> 
> Could you try this new patch on mod_http2 please?
> 
> Thanks,
> Yann.
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Eric Covener]

On Fri, Jan 20, 2017 at 12:47 PM, David Zuelke  wrote:
> I'd actually like to question the whole practice of porting features back to 
> older branches. I think that's the core reason why trunk is in total 
> disarray, and why no substantial releases have been made. There is just no 
> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
> just backport whatever you want.

IMO trunk isn't in total disarray, and new releases haven't been made
because there's nobody working/waiting on anything that doesn't fit
into 2.4 as a continuous delivery release.   Maintenance has been just
as disruptive as new features.

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Am 20.01.2017 um 18:17 schrieb Yann Ylavic:
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
>  wrote:
>> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
>> pool. Not like before where i got many different ones.
> 
> Could you try this new patch on mod_http2 please?

status ist still used in the log_cerror function. compilation fails. For
now i just commented the ap_log_cerror call.

Stefan

> 
> Thanks,
> Yann.
> 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 01:46 schrieb Eric Covener :
> 
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr  
> wrote:
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>> would be deferred to and shipped as 3.0.
>> 
>> The httpd project choose to call 2.minor releases as breaking
>> changes. Due to poor design choices, or frequent refactorings,
>> this essentially shifted our release numbering schema down one
>> digit. So 2.6.0 is not an enhancement release, but a major release
>> in the general understanding of these things. This might be the root
>> of Jim's and my failure to come to any consensus.
>> 
>> Right now, there are a number of gratuitous breaking changes on trunk
>> that change binary ABI. I'm considering a trunk fork to preserve these
>> changes (branches/3.x-future/?) and reverting every change to trunk/
>> which was otherwise a no-op. Namespace, decoration, anything that
>> prevents a user from loading a 2.4.x module in 2.next. And then we
>> can look at what is a valid reason to take us to 3.0.
> 
> The  "why" missing here is presumably to allow a 2.6 to be cut from
> trunk. But in that case, why not just fork it from 2.4 w/o a major nor
> magic cookie bump and let 2.4 become the more conservative stream?

+1

Just some brainstorming:

LTS/Stable/Feature branches

2.2.x/2.4.x/2.6.xfor now
2.2.x/2.6.x/2.8.xif we think new features in 2.6 are stable and want to add 
more features
2.4.x/2.4.x/2.6.xif we end LTS for 2.2, the new LTS can be a stable branch
2.2.x/2.4.x/2.8.xin extreme cases, we could ditch a feature branch and move 
on.

- we continue working in trunk
- backports to LTS/stable branches as now, review then commit
- backports to feature branches: commit, then review
- LTS is the support promise, stable/feature can move more freely
- Feature is completely "experimental", we make no promises
- Distros can support stable longer than we do, which is basically the model 
they are doing now for their LTS.
- people will argue for more than 1 LTS release, but I think that is too much 
for the project, more something for a commercial undertaking

(and there could be odd version numbers in there as well, but does not matter 
to me)

> [...]

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: svn commit: r1779578 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml

[Luca Toscano]

2017-01-20 10:11 GMT+01:00 ste...@eissing.org :

>
> > Am 20.01.2017 um 09:45 schrieb elu...@apache.org:
> >
> > Author: elukey
> > Date: Fri Jan 20 08:45:40 2017
> > New Revision: 1779578
> >
> > URL: http://svn.apache.org/viewvc?rev=1779578=rev
> > Log:
> > Added more details to mod-proxy-http2's doc
> >
> > Modified:
> >httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> >
> > Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/
> mod/mod_proxy_http2.xml?rev=1779578=1779577=1779578=diff
> > 
> ==
> > --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml (original)
> > +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml Fri Jan 20
> 08:45:40 2017
> > @@ -41,9 +41,14 @@
> > have to be present in the server.
> >
> > mod_proxy_http2 works with incoming requests
> > -over HTTP/1.1 and HTTP/2 requests. If mod_http2
> > -handles the frontend connection, requests against the same HTTP/2
> > -backend are sent over a single connection, whenever possible.
> > +over HTTP/1.1 and HTTP/2 requests. In both cases, requests proxied
> > +to the same backend are sent over a single connection
> > +whenever possible (namely when the connection can be re-used).
> > +
> > +mod_proxy_http2 will not use the HTTP/2
> protocol
> > +when the frontend requests use HTTP/1.1.
> > +This means that HTTP/2 will be used to proxy requests to a capable
> backend
> > +only when the frontend requests use the same protocol.
> >
>
> Not correct. Maybe my explanation was not good. mod_proxy_http2 will
> always use HTTP/2 in the backend connection. That connection will however
> only do one request at a time if the frontend is HTTP/1.1.


No no it is me being slow to understand HTTP/2 related things :)

So mod-proxy-http2 will always use HTTP/2 with a "capable" backend, but it
will not exploit its full potential when the frontend requests are HTTP/1.1
(for example "translating" multiple proxied HTTP/1.1 requests into HTTP/2
streams over the same TCP connection).

Better? If not I can revert everything and leave you do it, might be better
:)

Thanks for the patience!

Luca

Re: svn commit: r1779578 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml

[ste...@eissing.org]

> Am 20.01.2017 um 09:45 schrieb elu...@apache.org:
> 
> Author: elukey
> Date: Fri Jan 20 08:45:40 2017
> New Revision: 1779578
> 
> URL: http://svn.apache.org/viewvc?rev=1779578=rev
> Log:
> Added more details to mod-proxy-http2's doc
> 
> Modified:
>httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> 
> Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml?rev=1779578=1779577=1779578=diff
> ==
> --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml (original)
> +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml Fri Jan 20 08:45:40 
> 2017
> @@ -41,9 +41,14 @@
> have to be present in the server.
> 
> mod_proxy_http2 works with incoming requests
> -over HTTP/1.1 and HTTP/2 requests. If mod_http2
> -handles the frontend connection, requests against the same HTTP/2
> -backend are sent over a single connection, whenever possible.
> +over HTTP/1.1 and HTTP/2 requests. In both cases, requests proxied
> +to the same backend are sent over a single connection
> +whenever possible (namely when the connection can be re-used).
> +
> +mod_proxy_http2 will not use the HTTP/2 protocol
> +when the frontend requests use HTTP/1.1.
> +This means that HTTP/2 will be used to proxy requests to a capable 
> backend
> +only when the frontend requests use the same protocol.
> 

Not correct. Maybe my explanation was not good. mod_proxy_http2 will always use 
HTTP/2 in the backend connection. That connection will however only do one 
request at a time if the frontend is HTTP/1.1.

> This module relies on http://nghttp2.org/;>libnghttp2
> to provide the core http/2 engine.
> 
> 

Re: svn commit: r1779578 - /httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml

[Stefan Eissing]

> Am 20.01.2017 um 10:35 schrieb Luca Toscano :
> 
> 
> 
> 2017-01-20 10:11 GMT+01:00 ste...@eissing.org :
> 
> > Am 20.01.2017 um 09:45 schrieb elu...@apache.org:
> >
> > Author: elukey
> > Date: Fri Jan 20 08:45:40 2017
> > New Revision: 1779578
> >
> > URL: http://svn.apache.org/viewvc?rev=1779578=rev
> > Log:
> > Added more details to mod-proxy-http2's doc
> >
> > Modified:
> >httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> >
> > Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml
> > URL: 
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml?rev=1779578=1779577=1779578=diff
> > ==
> > --- httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml (original)
> > +++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_http2.xml Fri Jan 20 
> > 08:45:40 2017
> > @@ -41,9 +41,14 @@
> > have to be present in the server.
> >
> > mod_proxy_http2 works with incoming requests
> > -over HTTP/1.1 and HTTP/2 requests. If mod_http2
> > -handles the frontend connection, requests against the same HTTP/2
> > -backend are sent over a single connection, whenever possible.
> > +over HTTP/1.1 and HTTP/2 requests. In both cases, requests proxied
> > +to the same backend are sent over a single connection
> > +whenever possible (namely when the connection can be re-used).
> > +
> > +mod_proxy_http2 will not use the HTTP/2 protocol
> > +when the frontend requests use HTTP/1.1.
> > +This means that HTTP/2 will be used to proxy requests to a capable 
> > backend
> > +only when the frontend requests use the same protocol.
> >
> 
> Not correct. Maybe my explanation was not good. mod_proxy_http2 will always 
> use HTTP/2 in the backend connection. That connection will however only do 
> one request at a time if the frontend is HTTP/1.1.
> 
> No no it is me being slow to understand HTTP/2 related things :)
> 
> So mod-proxy-http2 will always use HTTP/2 with a "capable" backend, but it 
> will not exploit its full potential when the frontend requests are HTTP/1.1 
> (for example "translating" multiple proxied HTTP/1.1 requests into HTTP/2 
> streams over the same TCP connection). 
> 
> Better? If not I can revert everything and leave you do it, might be better :)

Nonono. No easy way out: :)

You got it right, except one tiny detail: the backend *needs* to talk HTTP/2, 
there is no fallback to HTTP/1.1 by mod_proxy_http2. Which might be a feature 
for the future, or a folding of http/2 support into mod_proxy_http (far future).

> 
> Thanks for the patience!

Thanks for helping!

> 
> Luca

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de