Re: HTTP/2 and no-longer "experimental"

[Eric Covener]

On Wed, May 31, 2017 at 11:46 AM, William A Rowe Jr  wrote:
> I have the impression that mod_http2 implementation in 2.6 is
> already cleaner and more maintainable, owing to enhancements
> Stefan already contributed and those parts of the implementation
> that httpd 2.4 had subpar support for... leading to various bits of
> bubblegum and twists of bailing wire, which are harder to maintain
> without the 2.6 API fixes.

I think 2.4 and trunk mod_http2 are nearly identical.  In 2.4 we have
a copy of trunks ap_create_request() to create the dummy request_recs,
and not much else substantial in the diff.



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

Re: HTTP/2 and no-longer "experimental"

[William A Rowe Jr]

On May 31, 2017 1:32 PM, "Helmut K. C. Tessarek" 
wrote:

On 2017-05-31 11:46, William A Rowe Jr wrote:
> If my assumptions above are wrong, ignore this thought... but if
> the goal is to drive adoption of our 2.6 implementation of http2,
> then simply dropping "experimental" seems unwise. Upgrading
> its status from "experimental" (which I read as -alpha at best)
> to a "beta" release of mod_http2 in 2.4.26 might be a really good
> idea to drive interest in advance of 2.6, while averting a half-decade
> long support effort of that specific module on the already five year
> old stale branch.

This topic is also about perception. Most people won't use http2 in
production, if it is marked as experimental or beta. These people might
look at other server software instead.

How long will people have to wait for 2.6? This is a fair question,
because I have no idea what your plans are. But I guess it won't be for
a while (timeframe maybe even years?).


Very fair observation, which is the root of my question. If we don't intend
to support 2.4 http2 in parallel for years once 2.6 is released, those
users you mention would be wise not to deploy it in production. We see
plenty of httpd instances running 3-5 year old or much older versions.

Those users who keep their software refreshed frequently would be wise to
adopt http2 already, and those are the users we want to encourage.

Re: HTTP/2 and no-longer "experimental"

[Helmut K. C. Tessarek]

On 2017-05-31 11:46, William A Rowe Jr wrote:
> If my assumptions above are wrong, ignore this thought... but if
> the goal is to drive adoption of our 2.6 implementation of http2,
> then simply dropping "experimental" seems unwise. Upgrading
> its status from "experimental" (which I read as -alpha at best)
> to a "beta" release of mod_http2 in 2.4.26 might be a really good
> idea to drive interest in advance of 2.6, while averting a half-decade
> long support effort of that specific module on the already five year
> old stale branch.

This topic is also about perception. Most people won't use http2 in
production, if it is marked as experimental or beta. These people might
look at other server software instead.

How long will people have to wait for 2.6? This is a fair question,
because I have no idea what your plans are. But I guess it won't be for
a while (timeframe maybe even years?).

Cheers,
 K. C.

-- 
regards Helmut K. C. Tessarek
lookup http://pool.sks-keyservers.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/

Re: The drive for 2.4.26

[William A Rowe Jr]

The suggestion is to push out any 2.4 release indefinately for an
experimental feature which is promoted in another thread for promotion
to a GA designation?

Just a sanity check of my sense of irony :)

On Wed, May 31, 2017 at 6:59 AM, Jim Jagielski  wrote:
> I think we should wait on a T to resolve this issue...
>
>> On May 30, 2017, at 9:12 AM, Stefan Eissing  
>> wrote:
>>
>> I have one report of a CPU busy loop that seems to only happen on the last 3 
>> changes in mod_http2. Steffen is currently testing if a feature disable 
>> solves the problem and thus points to the cause. I hope to hear from him 
>> tomorrow sometime during the day if that addresses the issue or not.

Re: Ideas from ApacheCon

[Jim Riggs]

> On 23 May 2017, at 09:16, Jim Riggs  wrote:
> 
>> On 18 May 2017, at 13:22, Rainer Jung  wrote:
>> 
>> Am 18.05.2017 um 19:46 schrieb Jim Jagielski:
>>> Based on feedback from various sessions:
>>> 
>>> o A new-kind of "hot standby" in mod_proxy which kicks
>>>  in whenever a worker moves out of the pool (ie, doesn't
>>>  wait until all workers are out)... ala a redundant
>>>  hard drive.
>> 
>> Maybe "spare worker" (and we could have more than one such spares).
> 
> Exactly. I am already working on some code for this, though it to seems to 
> necessarily be a bit convoluted in the current codebase.
> 
> The way we treat a "hot standby" in mod_proxy_balancer is as a last-ditch 
> effort to return something. I.e. *all* workers are unavailable, so then we 
> use the hot standby. (This problem can actually be solved a different way by 
> setting a high value for lbset.)
> 
> In my mind, though, what is proposed here is actually how I actually expect a 
> "hot standby" to work. Think of it more like a "hot spare" in disk RAID 
> terms. That is, if *any* worker is unavailable, the hot spare will be used 
> (or at least added to the list of potential workers...still to be determined 
> by the lbmethod implementation).
> 
> Example:
> 
> 
> BalancerMember "http://192.168.1.50:80;
> BalancerMember "http://192.168.1.51:80;
> BalancerMember "http://192.168.1.52:80;
> BalancerMember "http://192.168.1.53:80; status=+H
> 
> 
> In this case, .53 will only get used if .50, .51, and .52 are *all* 
> unavailable.
> 
> 
> BalancerMember "http://192.168.1.50:80;
> BalancerMember "http://192.168.1.51:80;
> BalancerMember "http://192.168.1.52:80;
> BalancerMember "http://192.168.1.53:80; status=+R # new "hot spare" status
> BalancerMember "http://192.168.1.54:80; status=+R # new "hot spare" status
> 
> 
> In this case, if .50 becomes unavailable, .53 (or .54 depending on 
> implementation) will be treated as an available worker for the lbmethod to 
> potentially choose. If 2 or more of .50, .51, and .52 become unavailable, 
> both .53 and .54 would be available to be chosen.
> 
> So, instead of having a single fallback option when *all* workers are dead, 
> we will have a way of trying to ensure that a specific number of workers (3 
> in the example above) are always available...just like a hot spare drive 
> plugs into the RAID array when one of the members dies. In our case, though, 
> once the main worker recovers, the hot spare will go back to being a hot 
> spare (except for matching routes).
> 
> Comments welcome.


As promised, balancer hot spare support: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61140

Re: HTTP/2 and no-longer "experimental"

[William A Rowe Jr]

On Wed, May 31, 2017 at 7:07 AM, Jim Jagielski  wrote:
> There was discussion some time ago about dropping the "experimental"
> tag from our HTTP/2 implementation. It is causing loads of people
> to not use it, as well as allowing for the perpetuation of FUD that
> httpd really doesn't support HTTP/2.
>
> I'd like for 2.4.26 to be the release that removes that tag. It
> implies a transition to RTC in 2.4 for it, but I think that that
> is workable and realistic at this point...
>
> Thoughts? Comments?

If my understanding serves, "GA" would still be an inappropriate
title for the 2.4 branch... please review my assumptions...

I have the impression that the developers still believe HTTP/2
proxy is still 'experimental' / work-in-progress. Notably, there is
a large pile of duplicate functionality in the modules/http2/ tree
which should already be promoted to httpd util commons, so
one copy of these duplicated functions are shared by both
mod_http2 and mod_proxy_http2 (as well as potential http/2
enhancement modules).

I have the impression that mod_http2 implementation in 2.6 is
already cleaner and more maintainable, owing to enhancements
Stefan already contributed and those parts of the implementation
that httpd 2.4 had subpar support for... leading to various bits of
bubblegum and twists of bailing wire, which are harder to maintain
without the 2.6 API fixes.

I'm making the presumption that once we release 2.6, we will have
considerably less interest in backporting http2 enhancements back
to the 2.4 branch, certainly not over the timespan we backported
features from 2.4 back into 2.2 or 2.2 into 2.0. If this is true, leaving
the module as "not GA" in 2.4 leaves us much more latitude to focus
on only the critical and security corrections to 2.4 and put the energy
into further enhancing performance and usability in 2.6.

If my assumptions above are wrong, ignore this thought... but if
the goal is to drive adoption of our 2.6 implementation of http2,
then simply dropping "experimental" seems unwise. Upgrading
its status from "experimental" (which I read as -alpha at best)
to a "beta" release of mod_http2 in 2.4.26 might be a really good
idea to drive interest in advance of 2.6, while averting a half-decade
long support effort of that specific module on the already five year
old stale branch.

Re: HTTP/2 and no-longer "experimental"

[Graham Leggett]

On 31 May 2017, at 2:07 PM, Jim Jagielski  wrote:

> There was discussion some time ago about dropping the "experimental"
> tag from our HTTP/2 implementation. It is causing loads of people
> to not use it, as well as allowing for the perpetuation of FUD that
> httpd really doesn't support HTTP/2.
> 
> I'd like for 2.4.26 to be the release that removes that tag. It
> implies a transition to RTC in 2.4 for it, but I think that that
> is workable and realistic at this point...
> 
> Thoughts? Comments?

+1 to no-longer-experimental.

+1 to RTC.

Further ABI breaking improvements can target httpd v2.6.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Broken OCSP Stapling

[Hanno Böck]

Hi,

On Wed, 31 May 2017 07:45:23 -0500
Jim Riggs  wrote:

> This was mentioned in today's Bulletproof TLS newsletter
> (https://www.feistyduck.com/bulletproof-tls-newsletter/issue_28_lets_encrypt_downtime.html):
> 
> https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

I'm the author of that post, thanks for bringing that up.

In the meantime I found that there are even more bugs in the apache bz
that are unhandled that sound quite concerning. This one
https://bz.apache.org/bugzilla/show_bug.cgi?id=59049
is imho a security vulnerability, yet it's been ignored for over a year.


Please note also that I had some conversations with the Linux
Foundation / Core Infrastructure Initiative about OCSP stapling and
hey indicated that they would consider to provide funding if there's an
effort to improve the situation.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Broken OCSP Stapling

[Jim Riggs]

This was mentioned in today's Bulletproof TLS newsletter 
(https://www.feistyduck.com/bulletproof-tls-newsletter/issue_28_lets_encrypt_downtime.html):

https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

It discusses httpd's (and nginx's) broken OCSP stapling implementations. This 
is outside of my wheelhouse, but wanted to raise awareness for someone familiar 
with that code who may be interested in taking a look. The post references 
bz57121 from 2014(!).

Re: HTTP/2 and no-longer "experimental"

[Daniel Ruggeri]

+1!
-- 
Daniel Ruggeri


 Original Message 
From: Jim Jagielski 
Sent: May 31, 2017 7:07:21 AM CDT
To: httpd-dev 
Subject: HTTP/2 and no-longer "experimental"

There was discussion some time ago about dropping the "experimental"
tag from our HTTP/2 implementation. It is causing loads of people
to not use it, as well as allowing for the perpetuation of FUD that
httpd really doesn't support HTTP/2.

I'd like for 2.4.26 to be the release that removes that tag. It
implies a transition to RTC in 2.4 for it, but I think that that
is workable and realistic at this point...

Thoughts? Comments?

Re: HTTP/2 and no-longer "experimental"

[Eric Covener]

On Wed, May 31, 2017 at 8:07 AM, Jim Jagielski  wrote:
> There was discussion some time ago about dropping the "experimental"
> tag from our HTTP/2 implementation. It is causing loads of people
> to not use it, as well as allowing for the perpetuation of FUD that
> httpd really doesn't support HTTP/2.
>
> I'd like for 2.4.26 to be the release that removes that tag. It
> implies a transition to RTC in 2.4 for it, but I think that that
> is workable and realistic at this point...
>
> Thoughts? Comments?

I think we should drop the experimental label/treatment. If not now,
it seems like it's effectively permanent in 2.4.

HTTP/2 and no-longer "experimental"

[Jim Jagielski]

There was discussion some time ago about dropping the "experimental"
tag from our HTTP/2 implementation. It is causing loads of people
to not use it, as well as allowing for the perpetuation of FUD that
httpd really doesn't support HTTP/2.

I'd like for 2.4.26 to be the release that removes that tag. It
implies a transition to RTC in 2.4 for it, but I think that that
is workable and realistic at this point...

Thoughts? Comments?

Re: The drive for 2.4.26

[Jim Jagielski]

I think we should wait on a T to resolve this issue...

> On May 30, 2017, at 9:12 AM, Stefan Eissing  
> wrote:
> 
> I have one report of a CPU busy loop that seems to only happen on the last 3 
> changes in mod_http2. Steffen is currently testing if a feature disable 
> solves the problem and thus points to the cause. I hope to hear from him 
> tomorrow sometime during the day if that addresses the issue or not.
>