On Wed, Aug 26, 2015 at 12:08 PM, Jim Jagielski <[email protected]> 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/.
