The difficulty is that “header block” is also used to refer to the frame segment which contains the compressed headers.  You’ll need a different term for that, if you start using “header block” for a collection of headers as well.

Given that we’ve said the compression generates a single blob of output then gets spread across the frames, perhaps the thing inside a HEADERS frame is a “header block fragment”?

From: James M Snell [mailto:notifications@github.com]
Sent: Friday, June 28, 2013 9:49 PM
To: http2/http2-spec
Cc: Mike Bishop
Subject: Re: [http2-spec] HTTP Layer rework... (#151)


In draft-ietf-httpbis-http2.xml:

> +        </t>

> +        <t>

> +          If the total size of a compressed header block exceeds the expected

> +          maximum size allowed for an individual HEADERS or PUSH_PROMISE frame,

> +          the octets of the compressed header block are split among multiple

> +          individual frames that MUST be transmitted, in order, without any

> +          other interleaved frames. The frame carrying the final portion of

> +          the compressed header block MUST include a flag indicating that the

> +          header block is complete.

> +        </t>

> +        <t>

> +          Whenever this specification mentions sending a header block,

> +          the meaning is that one or more HEADERS frames containing the

> +          compressed content of a single header block is to be sent.

> +          Whenever sending a "push promise" is mentioned, the meaning

> +          is that one or more PUSH_PROMISE frames are being sent.

I changed from "sets of headers" to attempt to achieve some kind of consistency in the wording. Some places used "header block", other places used "sets of headers", other places talked about sequences of HEADERS frames, etc. We need to come up with clear language that states that a "Header block" is a logical set that can span either a sequence of PUSH_PROMISE frames or a sequence of HEADERS frames... wait... maybe that's the exact language we need ;-)

—
Reply to this email directly or view it on GitHub<https://github.com/http2/http2-spec/pull/151/files#r4951377>.