Re: Header Compression Implementation Feedback

Never mind, re-reading the latest draft I see the back reference and error handling are fully specified now...

On 2013-07-09, at 11:44 AM, Michael Sweet <msweet@apple.com> wrote:

> 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
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 9 July 2013 15:52:00 UTC