Re: What we call "headers"

Willy Tarreau <> Wed, 18 March 2020 04:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2B9D3A1054 for <>; Tue, 17 Mar 2020 21:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KMP1q4ccNCkn for <>; Tue, 17 Mar 2020 21:19:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEC203A104F for <>; Tue, 17 Mar 2020 21:19:22 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jEQ7e-0004c3-6D for; Wed, 18 Mar 2020 04:16:02 +0000
Resent-Date: Wed, 18 Mar 2020 04:16:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jEQ7b-0004b0-21 for; Wed, 18 Mar 2020 04:15:59 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jEQ7Z-0007AB-1k for; Wed, 18 Mar 2020 04:15:58 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 02I4FaWH012346; Wed, 18 Mar 2020 05:15:36 +0100
Date: Wed, 18 Mar 2020 05:15:36 +0100
From: Willy Tarreau <>
To: "Roy T. Fielding" <>
Cc: Mark Nottingham <>, HTTP Working Group <>, Julian Reschke <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jEQ7Z-0007AB-1k b51640dbcc6ef170c931d0d5777f9ac4
Subject: Re: What we call "headers"
Archived-At: <>
X-Mailing-List: <> archive/latest/37455
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Roy,

On Tue, Mar 17, 2020 at 04:37:20PM -0700, Roy T. Fielding wrote:
> > On Mar 16, 2020, at 11:38 PM, Mark Nottingham <> wrote:
> > 
> > A little while back we made some changes in http-core regarding terminology and headers. This seems to have caused some confusion and comment, so I thought I'd summarise where I think we're at (Julian and Roy might want to chime in if they feel differently or want to add nuance). 
> > 
> > Note that this is _not_ a call to bikeshed the chosen terms*.
> > 
> > The corresponding spec text is at <>, although of course we're still working on it.
> It might be easier to see the changes vs 7231 in this diff
> <>
> One thing I noticed was that section 4 now says there are two separate areas
> where fields can occur. I would prefer to define it as a possibly empty header
> section and zero or more trailer sections

I like this approach a lot. It's just like when people tell me they've
seen "the double CRLF which delimits the body", I say "no, you've seen
the empty field that marks the end of the header section".

And software made to process header fields and calling them "headers"
are not really designed to apply the same processing to trailers, so
even in such software it would be easier to consider that there is
processing of header and trailer fields rather than saying that these
fields are "headers". This way it will be easier to add explicit support
of trailers or mid-stream fields later in such software than trying to
adapt them to process everything as headers.