W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 12 Aug 2013 17:06:06 -0700
Message-ID: <CAP+FsNe1s5yHGUCPWrn15E=3m2B8_J9AJCekUGsQTpjmiPyUPg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Jeff Pinner <jpinner@twitter.com>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
That is no big deal-- you just emit an empty data frame with the flag set.
'Course this argument goes both ways...

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 Tuesday, 13 August 2013 00:06:35 UTC

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