About Padding in PUSH_PROMISE/HEADERS

Hi all,

The spec says padding of PUSH_PROMISE/HEADERS should be done in this way
<http://http2.github.io/http2-spec/#HEADERS>, which makes sense in normal
circumstances. However, when "Header Block Fragment" gets bigger and gets
splitted/transmitted in the following CONTINUATION frames, the way of doing
padding is unspecified.

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.

Any thoughts?

Thanks
Raullen Chai

Received on Tuesday, 7 October 2014 22:00:46 UTC