Il giorno sab 28 set 2019 alle ore 00:19 William A Rowe Jr
ha scritto:
>
> On Fri, Sep 27, 2019 at 10:48 AM Eric Covener wrote:
>>
>> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
>> wrote:
>> >
>> > On 2019-09-27 03:00, Stefan Eissing wrote:
>> > > I know of no plans to implement HTTP/3 support in Apache httpd.
>> >
>> > I'm sorry, but this seems rather strange to me. So what's the idea behind
>> > this
>> > decision (or better said the lack of a plan)?
>
>
> It's helpful to understand the nature of the ASF. We are always an incubator
> of great solutions written in code. But there is no ombudsman, no dictates
> which direct projects to do X, Y or Z when it comes to the code that our
> projects create. No demands of implementing features, etc. Everything that
> someone steps up to offer end up right here for discussion on dev@.
>
> There is no planning cabul, or even budget to put this on some coders
> to accomplish. You certainly can add an enhancement request on our
> bugzilla tracker to suggest this, but it is on some motivated party to bring
> the development effort to the table.
>
>>
>> HTTP/3 would be a lot of work, a lot of shoehorning into HTTPD, and
>> likely be de-stabilizing for quite some time. There is
>> simply nobody (seemingly) working on it.
>
>
>>
>> HTTPD is great and familiar to lots of people, but HTTPD'S age brings
>> a lot of baggage. Lots of other great servers have much
>> less baggage and currently have much more commercial interest and buzz.
>
>
> And it is engineered as an http/1 server. While we can now (with all props
> to Stefan and Tatsuhiro) claim http/2, we don't have the framework to really
> offer great h2 push support and other architecture required for long-lived
> dynamic request pipelines. http/2 and http/3 offer server-originated
> transactions that httpd never anticipated. That would be an entirely new
> module which both mod_http2 and mod_http3 would want to build on,
> and an entirely new definition of the CGI spec and related modules.
>
> So we "speak" http/2 now, and might speak http/3 sooner or later with
> Google's quiche or some other provider. But the server isn't constructed
> to be attentive to both the client's traffic demands and the backend's
> desire to push unsolicited traffic. That would be a fun chasm for some
> coders to jump, and we would welcome them here.
Very nice summary, I'd love to challenge it with a follow up question
(for everybody) - would it be good to start listing some of the
"desired features" somewhere, and find somebody in the community that
could work on them separately? We have a big community and doing the
whole mod_h3 thing might be scary at first sight, meanwhile a more
scoped and challenging project could be appealing. I think that Stefan
did a terrific job in developing mod_h2, we could start from the list
of things that httpd could improve to better support mod_h2. I am
fairly ignorant about the subject but I recall bucket beams
(https://icing.github.io/mod_h2/beams.html) or the fact that mod_h2
has its own set of workers (that may be integrated in mpm-event for
example, IIRC it was discussed in the past). These are only two
examples (that are probably not among the priorities), there are
plenty of things, and they may be the driver to finally push httpd 2.6
(or even more) out if needed.
On the other side, it is true that HTTP/2 and HTTP/3 are often used
only at the border of an infrastructure (reverse proxies etc..) and
HTTP is still probably predominant inside, where there are less
limitations. Knowing that ATS is already working on HTTP/3 is
reassuring on this front, but eventually it would be great that httpd
will do the same. Not saying that httpd is not good as reverse proxy,
just that nowadays light/simple/specialized reverse-proxy + TLS + H/2
have grown a lot in number, and it is easier for them to support new
protocol due to their more recent code history.
Luca
