- From: Raullen Chai <raullenchai@google.com>
- Date: Tue, 7 Oct 2014 15:00:19 -0700
- To: ietf-http-wg@w3.org
- Cc: Michaela LaVan <mlavan@google.com>
Received on Tuesday, 7 October 2014 22:00:46 UTC
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