Re: About Padding in PUSH_PROMISE/HEADERS

On 7 October 2014 15:00, Raullen Chai <raullenchai@google.com> wrote:
> Talked with Michaela LaVan and there are two obvious options:
> 1. pad the leading PUSH_PROMISE/HEADERS frame and defer the transmission of
> data payload to the next CONTINUATION frame. This is consistent with the
> current spec but seemingly violates the design rationale that all data
> payload should be transmitted at first, e.g., transmitting padding payload
> first introduces latency.
> 2. set the PADDED flag and Pad Length in the leading PUSH_PROMISE/HEADERS
> and put the actual padding payload in the last CONTINUATION frame which
> seems to be more consistent with the design rationale. However, this
> behavior is unspecified and adds some complexity.

I think that the logic is simple.  You determine the size of the
header block.  Then determine how much padding is needed.  If
length[block] + length[pad] > remaining, add the padding to the
initial HEADERS/PUSH_PROMISE, add whatever payload fits in the
remaining HEADERS/PP space, then add CONTINUATION frames for any left
over.

I don't think that this is complicated.  It's just limited.  You can
only add <= 256 bytes of padding to any header block.

Received on Tuesday, 7 October 2014 22:15:50 UTC