Re: HEADERS and flow control

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?

Yoav