Il giorno sab 28 set 2019 alle ore 00:19 William A Rowe Jr <[email protected]> ha scritto: > > On Fri, Sep 27, 2019 at 10:48 AM Eric Covener <[email protected]> wrote: >> >> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek >> <[email protected]> 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
