Re: #305 Header ordering

On Thu, Nov 21, 2013 at 2:20 PM, Martin Thomson <martin.thomson@gmail.com>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).
>

Yup.

#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.
-=R



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