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

From: Patrick McManus <[email-masked]>
Date: Fri, 26 Jul 2013 14:14:10 -0400

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

-Patrick

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jul 2013 00:48:49 -0700

On 26 July 2013 11:14, Patrick McManus <[email-masked]> wrote:
> 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).
>
> 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 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

---

From: James M Snell <[email-masked]>
Date: Mon, 29 Jul 2013 13:54:35 -0700

When going through the implementation on this, I couldn't help but
think that a special-purpose continuation frame type would actually be
best here.. to keep this kind of issue from coming up at all.

Right now, if I send a header block that needs to be split across
multiple HEADERS frames, there is some ambiguity about whether the
frame header of each of those HEADERS frames need to be identical
other than the END_HEADERS flag. If the HEADERS frame contains the
Priority field, does the priority field need to be set in every
continued HEADERS frame? Does the value need to be the same? If I
change the Priority value in each does it change the priority each
time?

Similar issue with the PUSH_PROMISE...

...It's also a bit wasteful of bytes on the wire (e.g. if I sent
continued PUSH_PROMISE frames, every one would be required to contain
the 4-byte promised stream identifier even tho really really only need
the first frame in the sequence to have it).

It would almost be (just a bit) easier to have a special
CONTINUED_HEADERS frame type such that... If I send a HEADERS frame
where END_HEADERS is NOT set, the next N-frames MUST be
CONTINUED_HEADERS until END_HEADERS is set. The only flag on
CONTINUED_HEADERS is END_HEADERS and the payload is a header block
fragment only. Likewise with PUSH_PROMISE.. if I send a PUSH_PROMISE
frame where END_HEADERS is NOT set, the next N-frames MUST be
CONTINUED_HEADERS until END_HEADERS is set.