You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2015/08/26 15:44:36 UTC

proposed backport, mod_h2 github release

I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know.

For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. 

Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently?

Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back.

Cheers,

  Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Re: proposed backport, mod_h2 github release

Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Aug 26, 2015, at 2:55 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Wed, Aug 26, 2015 at 1:52 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> 
> > On Aug 26, 2015, at 2:25 PM, Stefan Eissing <st...@greenbytes.de> wrote:
> >
> > Well, let's have a look at the core changes and discuss specifics.
> >
> > There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations.
> 
> I agree with you, looking forward to other reviewers, too.
>  
> > But I might be wrong. Let's review that patch and see.
> >
> 
> Even so, mod_h2 is hardly the 1st such module that adds fields to the
> end of core structs...
> 
> Why are people proposing throwing stop-sticks in our path??
> 
> Jim, why are you taking code review as a personal affront?  Could we cool it, please?

"code review"??? None of what you have proposed could be lumped under
the heading of "code review". Hardly.

Re: proposed backport, mod_h2 github release

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 26, 2015 at 1:52 PM, Jim Jagielski <ji...@jagunet.com> wrote:

>
> > On Aug 26, 2015, at 2:25 PM, Stefan Eissing <
> stefan.eissing@greenbytes.de> wrote:
> >
> > Well, let's have a look at the core changes and discuss specifics.
> >
> > There are only additions. Hooks and functions. And fields added to
> core_config. Unless some module is messing directly with that, I can see no
> need for recompilations.
>

I agree with you, looking forward to other reviewers, too.


> > But I might be wrong. Let's review that patch and see.
> >
>
> Even so, mod_h2 is hardly the 1st such module that adds fields to the
> end of core structs...
>
> Why are people proposing throwing stop-sticks in our path??
>

Jim, why are you taking code review as a personal affront?  Could we cool
it, please?

Re: proposed backport, mod_h2 github release

Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Aug 26, 2015, at 2:25 PM, Stefan Eissing <st...@greenbytes.de> wrote:
> 
> Well, let's have a look at the core changes and discuss specifics. 
> 
> There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations.
> 
> But I might be wrong. Let's review that patch and see. 
> 

Even so, mod_h2 is hardly the 1st such module that adds fields to the
end of core structs...

Why are people proposing throwing stop-sticks in our path??


Re: proposed backport, mod_h2 github release

Posted by Stefan Eissing <st...@greenbytes.de>.
Well, let's have a look at the core changes and discuss specifics. 

There are only additions. Hooks and functions. And fields added to core_config. Unless some module is messing directly with that, I can see no need for recompilations.

But I might be wrong. Let's review that patch and see. 

//Stefan

> Am 26.08.2015 um 19:39 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
>> On Wed, Aug 26, 2015 at 12:08 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> ?? I can't quite grok what you mean:
>>         I'm dubious that we are going to be able to meet the
>>         criteria that modules built for httpd 2.4.x will continue to
>>         function correctly without recompilation under 2.4+refactoring
>> 
>> could you explain??
> 
> I'm happy to.  I'm not talking about mod_h2 itself, but the API refactoring in core.
>  
>> It seems to me that considering that the h2 module on Github was
>> specific to Apache 2.4, I don't see why we need to add delays or
>> processes to officially add http/2 support, via the h2 module, to
>> 2.4.
>> 
>> The whole intent was always that h2 would provide a feedback loop between
>> itself and 2.6/3.0 regarding re-architecturing some aspects, but that
>> doesn't mean we "withhold" http/2 from 2.4. Of course the h2 module
>> under 2.4 will be different from what is eventually in 2.6/3.0. But 
>> so what?
>  
> I think we are on the same page - hopefully mod_h2 can 'fit' within the current API, or we succeed in working out those API backports such that that modules do not -need- to be aware of the change to the API that happened after they were compiled.
> 
> The change we made for http trailers was draconian, and forced us to break our agreement in the name of security, and I hope we can avoid repeating the issue.  (And we avert that sort of issue in the future with _create accessors for httpd structures.)
> 
> If the committers decide that twisting the API or mod_h2 itself to shoehorn it into 2.4 is too much, then 2.6 (or 3.0) is still a possibility, and tagging the state of our 2.5.x development as an -alpha should help us start cleaning up the state of trunk/.

Re: proposed backport, mod_h2 github release

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 26, 2015 at 12:08 PM, Jim Jagielski <ji...@jagunet.com> wrote:

> ?? I can't quite grok what you mean:
>         I'm dubious that we are going to be able to meet the
>         criteria that modules built for httpd 2.4.x will continue to
>         function correctly without recompilation under 2.4+refactoring
>
> could you explain??
>

I'm happy to.  I'm not talking about mod_h2 itself, but the API refactoring
in core.


> It seems to me that considering that the h2 module on Github was
> specific to Apache 2.4, I don't see why we need to add delays or
> processes to officially add http/2 support, via the h2 module, to
> 2.4.
>
> The whole intent was always that h2 would provide a feedback loop between
> itself and 2.6/3.0 regarding re-architecturing some aspects, but that
> doesn't mean we "withhold" http/2 from 2.4. Of course the h2 module
> under 2.4 will be different from what is eventually in 2.6/3.0. But

so what?


I think we are on the same page - hopefully mod_h2 can 'fit' within the
current API, or we succeed in working out those API backports such that
that modules do not -need- to be aware of the change to the API that
happened after they were compiled.

The change we made for http trailers was draconian, and forced us to break
our agreement in the name of security, and I hope we can avoid repeating
the issue.  (And we avert that sort of issue in the future with _create
accessors for httpd structures.)

If the committers decide that twisting the API or mod_h2 itself to shoehorn
it into 2.4 is too much, then 2.6 (or 3.0) is still a possibility, and
tagging the state of our 2.5.x development as an -alpha should help us
start cleaning up the state of trunk/.

Re: proposed backport, mod_h2 github release

Posted by Jim Jagielski <ji...@jaguNET.com>.
?? I can't quite grok what you mean:
	I'm dubious that we are going to be able to meet the
	criteria that modules built for httpd 2.4.x will continue to
	function correctly without recompilation under 2.4+refactoring

could you explain??

It seems to me that considering that the h2 module on Github was
specific to Apache 2.4, I don't see why we need to add delays or
processes to officially add http/2 support, via the h2 module, to
2.4.

The whole intent was always that h2 would provide a feedback loop between
itself and 2.6/3.0 regarding re-architecturing some aspects, but that
doesn't mean we "withhold" http/2 from 2.4. Of course the h2 module
under 2.4 will be different from what is eventually in 2.6/3.0. But
so what?

> On Aug 26, 2015, at 11:20 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing <st...@greenbytes.de> wrote:
> I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know.
> 
> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS.
> 
> Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently?
> 
> Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back
> 
> Looking forward to reviewing the code this week!
> 
> At the moment, I'm dubious that we are going to be able to meet the criteria that modules built for httpd 2.4.x will continue to function correctly without recompilation under 2.4+refactoring, but that's an absolute requirement of our versioning promises.  In such a case, 2.6.x (or 3.0.0) would become a top priority.  So there's that to consider.
> 
> I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the ApacheCon Core in Budapest.  We make no promises about the API between 2.5.0 and 2.5.x and users are expected to recompile their modules while working on that bleed branch.
> 
> 
> 


Re: proposed backport, mod_h2 github release

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 26, 2015 at 10:20 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing <
> stefan.eissing@greenbytes.de> wrote:
>
>> I just submitted my first backport STATUS update. Hope I did everything
>> ok, otherwise please let me know.
>>
>> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one
>> is the patch to core/mod_ssl that introduces Protocols. That is now in
>> STATUS.
>>
>> Next would be a patch for modules/http2 which is basically all source
>> files, changes in build and docs. Since there are many new files, does it
>> sense to make a patch for that or do we handle that differently?
>>
>> Also: since there were some people testing the github releases in their
>> own setups, I thought it helpful to let them test the core patch and mod_h2
>> as it currently is. I made a new release of mod_h2 on github which
>> basically downloads httpd 2.4.16, applies the core patch and builds the
>> mod_h2 copy against it. Hopefully some people take it out for a spin and
>> report back
>
>
> Looking forward to reviewing the code this week!
>
> At the moment, I'm dubious that we are going to be able to meet the
> criteria that modules built for httpd 2.4.x will continue to function
> correctly without recompilation under 2.4+refactoring, but that's an
> absolute requirement of our versioning promises.  In such a case, 2.6.x (or
> 3.0.0) would become a top priority.  So there's that to consider.
>
> I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the
> mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the
> ApacheCon Core in Budapest.  We make no promises about the API between
> 2.5.0 and 2.5.x and users are expected to recompile their modules while
> working on that bleed branch.
>

Moving feedback back to the backport considerations thread...

> > Btw. if you review the core_protocols.patch and find anything
preventing a backport, please let me know asap. I personally would like to
avoid a repeat of the ALPN back porting stop due to lack of time to find a
proper solution.

Of course!  The underlying guideline is that all modules built for
2.4.16, blissfully unaware of the 'future' Protocols schema, still "just
work" without recompilation or reconfiguration.  If this proves impossible,
the backport solution is probably to keep H2Protocols in place on any
legacy module, and reserve the generic Protocols for trunk and future
releases.

ASF mod_ftp is an example of an alternate protocol provider that (as of
trunk flavor) should still just work.  It happens to be the most convenient
for me to compare, but is by no means the only example.  I have a couple
patches to integrate before proposing a mod_ftp 1.0.1 tag for a release
vote, but expect to immediately afterwards start to integrate the proposed
Protocols behavior in httpd trunk, and be ahead of the game this round
rather than behind in the case of 2.4.x :)

Re: proposed backport, mod_h2 github release

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Aug 26, 2015 at 8:44 AM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:

> I just submitted my first backport STATUS update. Hope I did everything
> ok, otherwise please let me know.
>
> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is
> the patch to core/mod_ssl that introduces Protocols. That is now in STATUS.
>
> Next would be a patch for modules/http2 which is basically all source
> files, changes in build and docs. Since there are many new files, does it
> sense to make a patch for that or do we handle that differently?
>
> Also: since there were some people testing the github releases in their
> own setups, I thought it helpful to let them test the core patch and mod_h2
> as it currently is. I made a new release of mod_h2 on github which
> basically downloads httpd 2.4.16, applies the core patch and builds the
> mod_h2 copy against it. Hopefully some people take it out for a spin and
> report back


Looking forward to reviewing the code this week!

At the moment, I'm dubious that we are going to be able to meet the
criteria that modules built for httpd 2.4.x will continue to function
correctly without recompilation under 2.4+refactoring, but that's an
absolute requirement of our versioning promises.  In such a case, 2.6.x (or
3.0.0) would become a top priority.  So there's that to consider.

I'd like to RM a 2.5.0-alpha release on Friday 11 Sept, that would put the
mod_h2 + refactoring into the hands of bleeding edge adopters, ahead of the
ApacheCon Core in Budapest.  We make no promises about the API between
2.5.0 and 2.5.x and users are expected to recompile their modules while
working on that bleed branch.

Re: proposed backport, mod_h2 github release

Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 26.08.2015 um 23:21 schrieb Gregg Smith <gl...@gknw.net>:
> 
> On 8/26/2015 6:44 AM, Stefan Eissing wrote:
>> I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know.
>> 
>> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS.
> 
> Needs r1693918, other than that all seems ok so far :)

Thanks, nice catch. This C89 thing is killing me...

Updated STATUS and patch file on github.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Re: proposed backport, mod_h2 github release

Posted by Gregg Smith <gl...@gknw.net>.
On 8/26/2015 6:44 AM, Stefan Eissing wrote:
> I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know.
>
> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS.

Needs r1693918, other than that all seems ok so far :)



Re: proposed backport, mod_h2 github release

Posted by Jim Jagielski <ji...@jaguNET.com>.
woooooot!!

> On Aug 26, 2015, at 9:44 AM, Stefan Eissing <st...@greenbytes.de> wrote:
> 
> I just submitted my first backport STATUS update. Hope I did everything ok, otherwise please let me know.
> 
> For backporting mod_h2 to 2.4.x, I decided to make it in two parts: one is the patch to core/mod_ssl that introduces Protocols. That is now in STATUS. 
> 
> Next would be a patch for modules/http2 which is basically all source files, changes in build and docs. Since there are many new files, does it sense to make a patch for that or do we handle that differently?

The patch could basically be set of SVN merges. Or a giant diff -r -u -N ;)

> 
> Also: since there were some people testing the github releases in their own setups, I thought it helpful to let them test the core patch and mod_h2 as it currently is. I made a new release of mod_h2 on github which basically downloads httpd 2.4.16, applies the core patch and builds the mod_h2 copy against it. Hopefully some people take it out for a spin and report back.
> 
> Cheers,
> 
>  Stefan
> 
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 


Re: proposed backport, mod_h2 github release

Posted by Stefan Eissing <st...@greenbytes.de>.
Latest is 1.0.2d, but the c will also do. 1.0.1 does not seem to have it.

> Am 27.08.2015 um 10:48 schrieb jean-frederic clere <jf...@gmail.com>:
> 
> Hi.
> 
> Just to clarify the openssl minimal version to use to have h2 working is 1.0.2c correct? Or did I miss something?
> 
> Cheers
> 
> Jean-Frederic

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Re: proposed backport, mod_h2 github release

Posted by jean-frederic clere <jf...@gmail.com>.
Hi.

Just to clarify the openssl minimal version to use to have h2 working is 
1.0.2c correct? Or did I miss something?

Cheers

Jean-Frederic