Thanks for the props! I detail my thoughts on h3 and httpd more below:
> Am 28.09.2019 um 00:18 schrieb William A Rowe Jr :
>
> 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.
Well said.
> 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.
From my work with h2 I can say that this baggage bit me for years from
various angles. I still have hope that we have climbed that mountain now.
> 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.
As I understand it, the core of httpd was designed when HTTP/1.0 was the
protocol (or a 0.9++ very close to it). The task it was designed to do is
processing HTTP requests (regardless of the version) and that it does still
exceptionally well today with tons of code hardened over time.
The part that "brings the HTTP requests in" was relatively simply at the
time, but there was already an abstraction layer of a "connection". However,
since HTTP/1.x was the only user, this was limited in variation.
Assumptions about what a "connection" is crept in and had to be sorted
when implementing h2. The most obvious was "there is only one request
active on the same connection". In HTTP/1.x it was inconceivable that this
would ever not be true.
> 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.
h3 is changing another assumption: that a "connection" is tied to a socket.
Instead, a h3 connection can have 0, 1 or (at least temporarily) several
UDP sockets at a time.
Then there is the issue to be solved how to route h3 packets to the child
httpd process handling the connection. Last I checked is that there were
some kernel patches for linux to facilitate this, but I have not kept track.
Very interesting work. But not a weekend project, IMO.
Cheers, Stefan
