- From: Yoav Nir <ynir.ietf@gmail.com>
- Date: Wed, 2 Jul 2014 16:56:55 +0300
- To: HTTP Working Group <ietf-http-wg@w3.org>
Not an implementer of HTTP myself - those are in the other building, but I do meet with them regularly (and no, we won’t have something ready in the relevant timeframe) I don’t believe that the interop and deployment experience from draft-13 will provide new information for this issue. I’d also like to point out that #2 has an issue with middleboxes. Middleboxes futz with headers. So a client or server may send headers that are less than 16K when HPACK’d, but after futzing and re-HPACK-ing, those can exceed 16K. So a client sends a HEADERS frame that seems entirely valid, only for the stream to be terminated by the proxy because of the excessive size of the headers. I would have been fine with jumbo-frames even if they’re only for headers (although I’d like them to be for everything), even if they were a negotiated option. But absent jumbo-frames on the menu, I’d go with #0. Yoav On Jul 2, 2014, at 2:12 PM, Mark Nottingham <mnot@mnot.net> wrote: > > 0) the status quo > > 1) <https://github.com/http2/http2-spec/pull/544> and variants thereof (e.g., not including CONTINUATION in flow control; alternative syntaxes) > > 2) limiting header sizes to 16K (HPACK’d) in HTTP/2, as per PHK’s suggestion > > There’s also another implicit option; > > 3) We can’t know until we get substantial interop and deployment experience with draft-13. >
Received on Wednesday, 2 July 2014 13:57:37 UTC