- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 11 Jul 2016 08:56:25 +0200
- To: Andy Green <andy@warmcat.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Yanick Rochon <yanick.rochon@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2016-07-11 08:37, Andy Green wrote: > ... >>> I'm a bit bemused why the world needs JSON headers instead of the >>> cool >>> stuff for header coding in http/2, but I can give one point of view >>> related to duplicate headers and efficiency. >>> ... >> >> I don't understand the "instead" here. The data model for header >> fields >> exactly the same in HTTP/1.1 and HTTP/2, so the proposed format >> applies >> to both. > > I mean now it exists and is formalized, and implementations exist, > shouldn't people be being encouraged to directly use HPACK? Doesn't parse. If you use HTTP/2, you always use HPACK. If you use HTTP/1.1, you never use HPACK. There is nothing to choose here. > Agreed, JSON would in retrospect be cooler than HTTP/1.x headers. But > I'm surprised there is any energy to go and make more ways to send HTTP > headers. Actually, it's an attempt to have *less* ways, in that it gives people defining new header fields a framework to use, instead of having to invent new micro-syntax every time. > Mightn't it be better to look at tweaking HPACK to have a "strict flag" > or somesuch to give some of the qualities discussed here, like only one > instance of each header? Otherwise HPACK is pretty nice. > > Apologies if I miss the point but JSON headers won't directly fly on > HPACK AFAICS, unless your idea is making an uber-header and its value > is the whole JSON payload. But that's needlessly incompatible when > it's dealing with the same traditional headers and values HPACK already > supports actually. They "fly" exactly the same way as in HTTP/1.1; could you elaborate on where you see a difference? Best regards, Julian
Received on Monday, 11 July 2016 06:57:18 UTC