Subject: HPACK: pseudo-headers ordering

From: Kaoru Maeda <[email-masked]>
Date: Wed, 6 Aug 2014 19:31:04 +0900

In HPACK-09 draft, header list ordering is described as:

> 3.1.  Header List Ordering
>
>    The compression and decompression process preserve the ordering of
>    header fields inside the header list.  An encoder SHOULD order header
>    field representations in the header block according to their ordering
>    in the original header list.  A decoder SHOULD order header fields in
>    the decoded header list according to their ordering in the header
>    block.
>
>    In particular, representations for pseudo-header fields (see
>    Section 8.1.2.1 of [HTTP2]) MUST appear before representations for
>    regular header fields in a header block.  In a decoded header list,
>    pseudo-header fields MUST appear before regular header fields.

IIUC, when the original header list (already) has a pseudo-header
after a regular header, it is _not_ HPACK implementation's
responsibility to bring the pseudo-header before regular headers.
The layer that generates the original list should take care of it.
HPACK should pass the (possibly prohibited) order unchanged.

Does the word "MUST" states that HPACK should bring pseudo-
headers to the beginning?

Or, should I read the spec as this?
- preserving the order of header field is a "SHOULD", and
- not reordering pseudo-headers out of the beginning of the header block is
a "MUST"
If this is the case, I suggest the following text:
   In particular, representations for pseudo-header fields (see
   Section 8.1.2.1 of [HTTP2]) MUST NOT be reordered so that
   they come after representations for regular header fields
   in a header block.  In a decoded header list,
   pseudo-header fields MUST NOT be reordered after
   any of regular header fields.

Regards,
-- 
Kaoru Maeda

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Aug 2014 11:37:24 -0700

> headers to the beginning?

The implication here by having this requirement in HTTP/2 and not HPACK, is
that the HTTP mapping maintains this.  Though this is largely a division of
responsibilities thing that we don't usually worry about here, you are free
to structure your code as you choose.  If I were building HPACK, I wouldn't
bother even looking at the header field names.