On Sun, Jun 28, 2020 at 5:53 AM Graham Leggett <minf...@sharp.fm> wrote:
> On 27 Jun 2020, at 14:48, Luca Toscano <toscano.l...@gmail.com> wrote: > > > the challenges are the same one discussed in your previous email > > thread ( > https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E > ). > > I think that everybody would love to start working/helping on adding > > HTTP/3 support but the work to be done is huge, involves invasive > > changes to the httpd's source code and the current dev resources don't > > have (rightfully) bandwidth to support the current codebase and plan a > > major refactoring. > > I would be careful with wide reaching statements like this. > > I’ve been working on identifying and removing blockers in various parts of > the httpd subsystems that prevent httpd to be cleanly event driven, and > most of those blockers have been removed. > > The underlying architecture of httpd is very strong, and would support new > protocols without too much trouble. > > The main point is that it must be done carefully and properly, but this is > not a reason to not do it at all. > I didn't read anyone saying "don't do it", in fact all the communication has said exactly the opposite. Irrespective of getting the code into a state where true async behavior "just works", and request handlers will have no problem with free threading (this is not true of PHP and other third party modules), that still leaves a huge hole. Right now, we couple httpd <-> mod_ssl <-> mod_http2 <-> nghttp2 <-> httpd filters and handler. This works, since the protocol layer exists apart from the SSL stack. What we are running up against at another project is the tight interconnect between the ssl protocol implementation and the quic implementation. They are almost insperable. You can't do this with mod_ssl out-of-the-box. There are hacks of mod_ssl to enable the callbacks and sideways ingress points which the quic transport protocol requires, but effectively it's a marriage between Google's quiche and boringssl, or another quic implementation and their elected ssl transport. So it might be that mod_ssl almost entirely disappears in this scenario, replaced by a triplet of httpd skin around one specific quic tightly coupled to one specific tls provider. The openssl project has published that following 3.0.0 GA, they are devoting energies into implementing all of the hooks into openssl required of a quic implementation (alongside building a FIPS crypto provider coupled to 3.0.0.) These were simply things that current 3.0.0 release plan couldn't accommodate, and they were further worried that the specifics of the spec weren't sufficiently ironed out during their pre-alpha development stage to commit to 10+ years of support for mangled API's. Tatsuhiro himself has been contributing commits to https://github.com/ngtcp2/nghttp3 although I have yet to read any specific roadmap or plan on what direction he is taking his efforts. At $dayjob OSS projects, it's largely been a matter of consuming his implementation of nghttp2, while consuming boringssl+quic to get to http3 for the time being. I don't think Luca's general guidance is off-base, nor that his cautions are at all misplaced, and he has perhaps taken a fair assessment of the complexity of this challenge.
