I think it might be better to move the logic off rather than add flags for all frames that might be continued. This keeps the mechanism as simple as possible -- i.e. extend the previous frame by "length" bytes until you see END_HEADERS flag. Then we don't have to worry about other flags (e.g. the reserved END_MESSAGE), or future extensible if CONTINUES is used for other frames with header blocks. On Mon, Aug 12, 2013 at 4:29 PM, Martin Thomson <martin.thomson@gmail.com>wrote: > On 12 August 2013 23:58, Jeff Pinner <jpinner@twitter.com> wrote: > > PUSH_PROMISE is hop-by-hop -- if you end the stream with a push promise > flag > > you have to tell intermediates to forward the flag on some other frame, > and > > that may or may not break the semantics of the layered application. > > This is a good point. It's especially bad if the intermediary already > forwarded the last frame. Not that we should be allowing that to > happen of course, since PUSH_PROMISE shouldn't be the last frame in a > response... > > I tend to think that prohibition is the most reasonable reaction. I'm > not that keen to move the END_STREAM bit off the last frame on the > stream, even if it is technically the same > but-we-had-to-split-it-up-a-little-so-that-it-fits frame. It spreads > the frame processing logic over multiple headers in ways that will > probably lead to implementation errors. >
Received on Monday, 12 August 2013 23:38:38 UTC