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

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.



On Fri, Jul 26, 2013 at 11:14 AM, 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)...
>
> -Patrick
>

Received on Monday, 29 July 2013 20:55:29 UTC