On 1 September 2014 09:34, Matthew Kerwin <matthew@kerwin.net.au> wrote: > Repeating myself again, but: what do you think of an option C: remove > Flags from the general frame header, and add individual Flags fields to > whichever frame types require them? Matthew, in general I think the framing layer should only know about framing concerns and should be neutral towards any semantics conveyed in the frame payloads. So in principal, yes I agree than general flags (and probably frame types other than those needed by framing) can easily be put into the payload. However, END_STREAM is a-priori a framing concern, so I don't think it should be moved to the frame payload or be a function of frame type. I would have preferred the framing layer was designed without HTTP semantic knowledge and was able to transport arbitrary bidirection flow controlled streams, perhaps with segments defined so that flushing/forwarding/segmentation behaviour can be guaranteed to a level needed. Other than what is required to achieve that, I see no reason that the framing layer should know any more about what it is transporting, even to the extent that it really should not know the difference between a header and data frame. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Monday, 1 September 2014 00:35:09 UTC