You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Alex Hautequest <hq...@hquest.pro.br> on 2019/09/26 17:54:16 UTC

Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support

With that, the obvious question: what about Apache?

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Stefan Eissing <st...@greenbytes.de>.
I think there are plenty resources online where you can find an answer to your question.

> Am 27.09.2019 um 09:18 schrieb Mark Blackman <ma...@exonetric.com>:
> 
> 
>> On 26 Sep 2019, at 18:54, Alex Hautequest <hq...@hquest.pro.br> wrote:
>> 
>> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
>> 
>> With that, the obvious question: what about Apache?
> 
> What’s the incentive to add it? 
> 
> 
> - Mark


Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Mark Blackman <ma...@exonetric.com>.
> On 26 Sep 2019, at 18:54, Alex Hautequest <hq...@hquest.pro.br> wrote:
> 
> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
> 
> With that, the obvious question: what about Apache?

What’s the incentive to add it? 


- Mark

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2019-09-27 10:40, William A Rowe Jr wrote:
> This answer \V/ (from Stefan) below. More explanation follows...

Thanks Bill, your explanation certainly helped to shed some light on this.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
This answer \V/ (from Stefan) below. More explanation follows...

The httpd project is entirely transparent. All development decisions occur
on the email
list you asked this question. Stefan himself stepped up to integrate
Tatsuhiro's nghttp2
implementation into httpd (very successfully) so we have mod_http2 as a
core module.

Something similar may happen where someone creates a mod_quic (google
obviously
hasn't shared such a thing, according to google search) or someone
integrates the
readily available implementations. We'll see, the Apache HTTP Server
project is very
welcoming of new community members who offer innovations like this (again
using
the example of Stefan, who quickly became a committer and PMC member after
bringing the mod_h2 proposal to the project.)

The troublesome part is that both HTTP/2 and HTTP/3 get ahead of their skis
by
being L4-L7 protocols, where HTTP/1 is L7. The httpd server was designed to
be
an OSI Layer 7 component. Stefan's done some great work breaking that design
model to have mod_http2 "fit" right in, but it's an uneasy fit.

Now HTTP/3 offers some very serious advantages, and the project was offered
some fun HTTP-over-UDP transport work over a decade ago. But any HTTP3/quic
component swaps out tls+mod_ssl+http+http2 work for an new and better
approach
to TLS  handshake negotiation and transport. It's going to be a fun
development
project for someone perhaps.

AFAIK no-one has expressed interest. But to anyone who has an interest, even
if you want to take such a project online, please share with dev@httpd that
you
are chasing the idea and maybe you'll find a great collaborator or few to
bring
a great proposal back to the project, once you decide it's ready for
submission.

Cheers,

Bill




On Fri, Sep 27, 2019 at 2:00 AM Stefan Eissing <st...@greenbytes.de>
wrote:

> I know of no plans to implement HTTP/3 support in Apache httpd.
>
> > Am 26.09.2019 um 19:54 schrieb Alex Hautequest <hq...@hquest.pro.br>:
> >
> >
> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
> >
> > With that, the obvious question: what about Apache?
>
>

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Luca Toscano <to...@gmail.com>.
Il giorno sab 28 set 2019 alle ore 00:19 William A Rowe Jr
<wr...@rowe-clan.net> ha scritto:
>
> On Fri, Sep 27, 2019 at 10:48 AM Eric Covener <co...@gmail.com> wrote:
>>
>> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
>> <te...@evermeet.cx> 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

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Stefan Eissing <st...@greenbytes.de>.
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 <wr...@rowe-clan.net>:
> 
> On Fri, Sep 27, 2019 at 10:48 AM Eric Covener <co...@gmail.com> wrote:
> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
> <te...@evermeet.cx> 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

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Sep 27, 2019 at 10:48 AM Eric Covener <co...@gmail.com> wrote:

> On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
> <te...@evermeet.cx> 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.

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Eric Covener <co...@gmail.com>.
> 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.

For a short time my employer talked about "two-speed IT" to frame how
different products address needs of existing projects vs.
new ones. The language is kind of replaced by e.g. "cloud native" but
it still kind of useful way to contrast some of these things.

-- 
Eric Covener
covener@gmail.com

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Alex Hautequest <hq...@hquest.pro.br>.
Although I should had made a few things clear, seems some good discussion happened. Amongst the same lines:

When I asked about Apache, I should had stated HTTPD. There is a QUIC implementation on Apache.org under ATS (Apache Traffic Server), a reverse proxy, load balancer daemon. While definitely an interesting approach that takes a ton of overhead from the web server, it adds much more than “just a mod_h3” to be maintained. Not that a mod_h3 wouldn’t be enough work to be maintained.

A motivator for the implementation is the continuity and evolution of the web we all know and rely on, which this very ancient dinosaur daemon helped to build and solidify. Apache may or may not have the largest market share amongst HTTP servers anymore, but it does not means it is stuck in time. As of h2, h3 is another evolution that should be looked at, when the time is right.

And while all is well said, it needs done. I too agree it might be a fun project for anyone with enough time, motivation and skills to do so. I fall short on at least one of these, so as much as the enthusiast of me would love to turn it on at my systems, I’m yet to remember how to code anything other than a bash script or minor automation tools in pre-made, 3rd party Python modules. Besides, h3 is not a full formal standard yet, so while it is showing signs it will be some day, it might be as QUIC is/was for a while before it settles up as standard. But it never hurt to be checked out.

Last but not least, thanks Stefan for your h2 work.

Alex

> On Sep 27, 2019, at 17:12, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
> 
> On 2019-09-27 11:47, Eric Covener wrote:
>> I don't think market share is a big motivating factor for active contributors.
> 
> Maybe not, but I remember a discussion a while back on this list that had to
> do with features vs stability, about market shares and why other web servers
> are gaining.
> 
>> 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.
> 
> I get that, I was simply saying that I didn't understand why there wasn't a
> plan. That's all.
> I also do understand that this might be a highly complex topic, especially
> since it will touch many components.
> I'm very grateful that Stefan took the initiative to get h2 into httpd.
> 
>> 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.
> 
> I've been using Apache httpd since the early days and I won't be switching to
> another web server. But the "baggage" can't be the reason for stagnation. A
> web server's main functionality is to serve web pages. If the protocol evolves
> so must the server, otherwise the server will be obsolete at one point in the
> future.
> 
> Cheers,
>  K. C.
> 
> -- 
> regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> 


Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Eric Covener <co...@gmail.com>.
> I'm very grateful that Stefan took the initiative to get h2 into httpd.
+1

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2019-09-27 11:47, Eric Covener wrote:
> I don't think market share is a big motivating factor for active contributors.

Maybe not, but I remember a discussion a while back on this list that had to
do with features vs stability, about market shares and why other web servers
are gaining.

> 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.

I get that, I was simply saying that I didn't understand why there wasn't a
plan. That's all.
I also do understand that this might be a highly complex topic, especially
since it will touch many components.
I'm very grateful that Stefan took the initiative to get h2 into httpd.

> 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.

I've been using Apache httpd since the early days and I won't be switching to
another web server. But the "baggage" can't be the reason for stagnation. A
web server's main functionality is to serve web pages. If the protocol evolves
so must the server, otherwise the server will be obsolete at one point in the
future.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Eric Covener <co...@gmail.com>.
On Fri, Sep 27, 2019 at 11:20 AM Helmut K. C. Tessarek
<te...@evermeet.cx> 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)?
>
> "Let's wait until other web servers implement it and wonder why they are
> gaining more market share?"
>
> I'm not mocking anyone, this is a honest question.

My 2c:

I don't think market share is a big motivating factor for active contributors.

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.

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
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)?

"Let's wait until other web servers implement it and wonder why they are
gaining more market share?"

I'm not mocking anyone, this is a honest question.

I also don't understand the statement:

> I think there are plenty resources online where you can find an answer to
> your question.

(as an answer to "What’s the incentive to add it? ")

In fact a web search does not yield any useful results. Furthermore the OP
most likely meant "what incentive would be required to add it".

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

Posted by Stefan Eissing <st...@greenbytes.de>.
I know of no plans to implement HTTP/3 support in Apache httpd.

> Am 26.09.2019 um 19:54 schrieb Alex Hautequest <hq...@hquest.pro.br>:
> 
> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
> 
> With that, the obvious question: what about Apache?