Re: Header Compression Implementation Feedback

Mike,

On 2013-07-09, at 11:00 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> No, you couldn't end up with that sequence as currently specced.  I agree, it would be an issue if the client did that, and you're right that there's no guarantee the individual HEADERS frame ends at a boundary -- but it's required to be the only frame type sent until a boundary is reached, and you are guaranteed to have reached a boundary at the end of the last HEADERS frame in the sequence.
> 
> From http://tools.ietf.org/html/draft-ietf-httpbis-http2-04:

Ah, I had been deep in section 6 and hadn't remembered the text earlier in section 4; perhaps it would be appropriate to include a back reference to section 4.3 in sections 6.2 and 6.6 as a reminder about the contiguous HEADER/PUSH_PROMISE frame requirements?

Also, if an implementation gets a bad HEADER/PUSH_PROMISE frame, would that fall under Connection Error Handling (5.4.1) or Stream Error Handling (5.4.2)?  If this is a connection error (which given that header tables are per-connection, I think it should be) then I think we need an error for headers - HEADER_ERROR (10) and PUSH_PROMISE_ERROR (11)?

That still leaves us with the added complexity/overhead of serializing headers, but I'll hold off on further comments until I have a more complete implementation to test with.

Thanks!

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 9 July 2013 15:45:28 UTC