Re: About Padding in PUSH_PROMISE/HEADERS

Yes, this is the specified way. Is the latency introduced by transmitting
the padding payload before transmitting the remaining data payload a
concern?

On Tue, Oct 7, 2014 at 3:15 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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