W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HEADERS and flow control

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Sun, 25 May 2014 17:46:49 +0300
Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DD96E638-D216-474A-AEC6-57C2B3C90CCD@gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>

On May 23, 2014, at 3:28 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> On 23 May 2014 04:08, Greg Wilkins <gregw@intalio.com> wrote:
> I think the hpack tail is really wagging this protocol dog!
> Currently hpack is forcing this protocol to have a user accessible non flow controlled un-segmentable size unlimited meta data streams that has strict ordering criteria resulting in significant parallel slow down.  
> ​It's also the single most complex part of the spec​ to implement. My side-project implementation has hiccupped and stalled every time it's bumped into continuation frames and hpack. I've currently stopped all work on it until I have time to go through and read in much more detail the hpack draft, and some related archived conversations on the list, and Canonical prefix encodings and Huffman coding, etc.
> If I could negotiate not using HPACK I could probably have the rest of my implementation up to some sort of interop testing by now.

I might be missing something basic here. But if you set the SETTINGS_HEADER_TABLE_SIZE to zero, doesn’t this effectively eliminate compression (and state!), leaving only encoding? ISTM that it works for a minimal client.  Am I correct in assuming that compression and state are the painful parts?

A minimal server could potentially receive a bunch of requests with compressed headers before the client receives the SETTINGS frame. But I’m sure that could be worked around, for example by closing all streams that have compressed headers. Not quite efficient, but if efficiency was the primary goal for this hypothetical server, it would implement HPACK.

What am I missing?

Received on Sunday, 25 May 2014 14:47:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC