Re: #305 Header ordering

On Thu, Nov 21, 2013 at 2:20 PM, Martin Thomson <>wrote:

> I think you're getting the proposal mixed up a little here.
> 1. We're creating special rules for Cookie, but those rules are
> separable.  One value emitted only (multiple carried).  No nulls
> needed there.

Unless/until we want to specify an order for Cookie, but even then ','
could be used.
I think we're on the same page on this.

> 2. Set-Cookie is already special, but since ordering doesn't matter,
> allow the compressor to emit these in any order, no concatenation.  It
> remains as a perpetual gotcha, but no proposal was going to change
> that characteristic.

I was saying that with null as the concatenation-separator one can safely
specify an order for Set-Cookie since we don't care about the ordering.
This is potentially useful in reducing the on-the-wire size of things.

> 3. Everything else already has rules for handling multiple header
> field name-value pairs.  Leverage those existing rules and require
> concatenate on encode to preserve order (unless you know that order
> doesn't matter, which might let you get some compression efficiency,
> c.f. cache-control).


#1 and #3 are very similar. #1 arguably has some small marginal benefits
over #3 (as I've been attempting to point out, if poorly :) ), the most
important of which is that it is already implemented.

> On 21 November 2013 14:08, Roberto Peon <> wrote:
> > We need a mechanism one way or another for fields where order might
> matter.

Received on Thursday, 21 November 2013 22:33:13 UTC