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

review: http2-10

From: Michael Köller <michael.koeller@greenbytes.de>
Date: Thu, 3 Apr 2014 21:36:12 +0200
Message-Id: <81F72605-BB1D-4960-838B-272464EA8C8F@greenbytes.de>
Cc: Julian Reschke <julian.reschke@greenbytes.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
Hi,

Julian asked me to do a review on the current draft of the HTTP/2 . 
My apologies, if my comments may have been discussed on the mailing list already. I tried to search the mailing list for answers, deleted some of the remarks I had noted down but still may have missed some threads.

4.3),  paragraph 7
> Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.
Me not being very familiar with the current state of http2, I was puzzled by the question: Why no interleaved frames?
I read mostly to the end and ahead into the referenced specs to deduce the reason: Header compression! 
I would like to see an informative sentence spent here about the stateful nature of header compression.


6.4) RST_STREAM
Is there a reason that this frame type does not carry an optional debug data field, like GOAWAY does? I can image same situations and use cases on both.
Speaking of debug data: Maybe the spec should advise about a reasonable default data format? Like a default encoding for text based data?


6.8), paragraph 4
> After sending a GOAWAY frame, the sender can discard frames for new streams. However, any frames that alter connection state cannot be completely ignored. For instance, HEADERS, PUSH_PROMISE and CONTINUATION frames MUST be minimally processed to ensure a consistent compression state (see Section 4.3)
The term "compression state" is undefined at this point. It results implicitly from the referenced header compression spec. That's another indicator that section 4.3 should tell something about the stateful nature of header compression.


Best regards,
Michael Köller



Received on Thursday, 3 April 2014 19:36:40 UTC

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