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

Re: question on non header block data of chained HEADERS and PP

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sun, 28 Jul 2013 00:48:49 -0700
Message-ID: <CABkgnnW1ixnvzz2azen1K1=jWHjtHviVX78bwmu641o6OzmvBQ@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 26 July 2013 11:14, Patrick McManus <pmcmanus@mozilla.com> wrote:
> HEADERS and PUSH PROMISE can have their header block fragmented among
> multiple contiguous frames. That's clear.
>
> For PP I'm a ltitle unusure how Promised-Stream-ID fits into those
> fragments. Is it present in all of them? the frame diagram seems to assert
> that it is present in every PP frame, but the definition of END_PUSH_PROMISE
> says "the payload of all PUSH_PROMISE frames are concatenated and
> interpreted as a single block". and the Promised-Stream-ID is definitely
> part of the definition of payload (which we have defined as everything after
> the first 8 bytes of frame header).
>
> The right thing is probably that it is present in all of them, but is not
> considered part of the payload for purposes of determining the header block.
> A clarification seems needed. If that's right, do we need a rule saying the
> Promised-Stream-ID must be the same across all the fragments?
>
> I think HEADERS has a similar problem with Priority.. it uses a "payload"
> definition of the headers block that would include priority (but
> shouldn't)...


I think perhaps I had concluded the opposite, but that was before the
priority flag, which can be on a continued frame.  It's not so easy.
I think that we need to pick something either way and write down the
conclusion.

https://github.com/http2/http2-spec/issues/183
Received on Sunday, 28 July 2013 07:49:18 UTC

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