W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: Is header order significant? [was: Concrete format for signed responses]

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 19 Dec 2017 17:26:00 +1300
To: Jeffrey Yasskin <jyasskin@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <69fa820b-6f33-de1f-9262-f0441183cbb9@treenet.co.nz>
On 19/12/17 13:59, Jeffrey Yasskin wrote:
> On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop wrote:
>     ... The advantage of your current scheme is that you can preserve
>     the original order of the headers in the signature, meaning a client
>     could detect changes / reconstruct them.  I’m not sure how critical
>     that is, but this is the right list to give feedback on the semantic
>     content of header ordering….____
>     ____
> Pulling this out to its own thread since it's more general than the 
> signed-exchange proposal:
> Is the order of HTTP headers semantically significant? Should future 
> proposals be careful to preserve header order, or is it ok to do things 
> like sort headers while processing them?

RFC 7230 section 3.2.2:
    The order in which header fields with differing field names are
    received is not significant.

but also:
    A recipient MAY combine multiple header fields with the same field
    name ... The order
    in which header fields with the same field name are received is
    therefore significant to the interpretation of the combined field
    value; a proxy MUST NOT change the order of these field values when
    forwarding a message.

So both yes and no. Depending on the particular message and headers 

That same section also has this advise on header ordering for 
applications that generate new messages, or do modifications:
    ... However, it is good practice to send
    header fields that contain control data first, such as Host on
    requests and Date on responses, so that implementations can decide
    when not to handle a message as early as possible.

Received on Tuesday, 19 December 2017 04:26:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:11 UTC