- From: Eitan Adler <lists@eitanadler.com>
- Date: Mon, 18 Dec 2017 20:07:57 -0800
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
On 18 December 2017 at 16:59, Jeffrey Yasskin <jyasskin@google.com> wrote: > On Wed, Dec 6, 2017 at 10:42 AM Mike Bishop <mbishop@evequefou.be> 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? >From RFC 7230: The order in which header fields with differing field names are received is not significant. 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. Note that this is only true for "differing field names": A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. 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. Set-Cookie is a special case. https://tools.ietf.org/html/rfc7230#section-3.2.2 -- Eitan Adler
Received on Tuesday, 19 December 2017 04:08:53 UTC