Re: [#228] PUSH_PROMISE with CONTINUATION can end a stream

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