- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Tue, 6 May 2014 10:09:21 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Larry Masinter <masinter@adobe.com>, Yoav Nir <ynir.ietf@gmail.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
On 5 May 2014 16:43, Julian Reschke <julian.reschke@gmx.de> wrote: > If HTTP/2 is inappropriate for a case where HTTP/1.1, that's a problem we > need to solve. This WG is chartered to define a new protocol version that > can *replace* HTTP/1.1. > > So I'd really like to see something more concrete than "it's too complex". > After all, correctly parsing text messages is complex as well, and that part > is gone in HTTP/2. > > Best regards, Julian I think that ship has sailed. It's been my understanding and expectation that HTTP/2 is simply not going to replace HTTP/1.1 wholly and completely. The complexity increase in terms of quantity of code in any language that has basic text-parsing functionality built-in (i.e. not C) from HTTP/1.1 to HTTP/2 is so astronomical that it's staggering. Logic is added for maintaining multiple sets of independent state (connection state, stream state, per-stream header compression state, per frame compression state). There are plenty of excellent gains to be achieved by this increase in complexity, but we shouldn't be pretending that HTTP/2 can be used everywhere HTTP/1.1 can. HTTP/2 is also harder to debug than HTTP/1.1, even if we exclude the fact that most HTTP/2 connections will be over TLS-with-PFS and will therefore be painful to intercept and trace. Certainly, in the world of client side HTTP libraries we're expecting that HTTP/2 will not supplant HTTP/1.1. We're not even sure that HTTP/2 will become the default.
Received on Tuesday, 6 May 2014 09:09:49 UTC