- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Tue, 19 Jul 2016 09:52:14 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Sorry for replying to myself, I forgot to say... On 19/07/2016, Matthew Kerwin <matthew@kerwin.net.au> wrote: > > I may be misremembering, but weren't a few "difficult" issues (like > efficient binary headers) kept out of H2 precisely because H3 could > be, relatively speaking, just around the corner? H2 has blazed a > trail; people are coming on board with the idea of new web protocols, > ALPN is a demonstrable success, the idea of 'evergreen servers' seems > to be emerging. This all says to me that the jump from H2 to H3 should > be much smoother than 1.x to 2 (and that hasn't exactly been rough.) > > Also, since we dropped the Minor protocol version number, doesn't that > suggest that the step from H2 to H3 could be quite.. well.. minor? In > fact, the smaller the better -- we're still learning how to > rearchitect our sites for H2's streaming model; if we keep that model > but improve some background properties there's a gain to be had by > upgrading, with no hidden cost. > > No need to reach for the stars, every improvement is an improvement > (if it's incremental *enough*.) > Back on topic, all that is to say that this is completely irrelevant to 1.x, and probably irrelevant to 2. I don't think JSON is the best fit for structured headers, but something like it could work. If it's ASCII it will already work ok with HPACK's Huffman coding. If we target something that fits with a pure binary H3 format then all the better. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Monday, 18 July 2016 23:52:43 UTC