Re: New precondition fields and caching

Mark Nottingham <> Tue, 08 September 2020 05:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6C5C3A1272 for <>; Mon, 7 Sep 2020 22:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=V0qyp4uh; dkim=pass (2048-bit key) header.b=VT0ji34E
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ukh1tPfJqhz0 for <>; Mon, 7 Sep 2020 22:15:13 -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 9721C3A1271 for <>; Mon, 7 Sep 2020 22:15:12 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kFVvw-000813-MJ for; Tue, 08 Sep 2020 05:12:44 +0000
Resent-Date: Tue, 08 Sep 2020 05:12:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFVvu-00080B-9P for; Tue, 08 Sep 2020 05:12:42 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFVvs-0001Wm-EL for; Tue, 08 Sep 2020 05:12:42 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id BC2D15C0143; Tue, 8 Sep 2020 01:12:26 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 08 Sep 2020 01:12:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=l rt7RmmCaw49dEaZrT0j2COHN+gIcEDrbtRdz1Nuvow=; b=V0qyp4uhJY2ofE1LC Qs5IRpUQhEbUUc6NzZceUvemZAc5EPcjH1yWKOi9uI+/69XRhkoBLUpWTF9hTQ+R 9Fm9oo2fwso1WmRUovOjRzQBvjH3QYQJrXBqiArSIVFnbaMk+tkOjPqTqxPmw3A/ 3tu88OuhhzktrkUbHg2bi1gZeSF8XcT3hjyOgTCAiI5oVgFPCAwsdQBEV+io+pop ot5T9IvPVnCpZJwlBVIw00YQIPgaWcLRDlPbLcnBYfiEFRyDmBwt4TPuun3WU9Ar NFS2UVGHENtiq2mKVrSLTUvdbhGh1hwsF/Y/vFw5kFOqfq++pUaZ0RmFZjrTWING mTUVw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=lrt7RmmCaw49dEaZrT0j2COHN+gIcEDrbtRdz1Nuv ow=; b=VT0ji34ECuwI/q9eyXlPkm5GEKd/yZZ49reoPY8Ug8jMh+m0bYowJazD8 7XvgxB7wVS3Ap4Nf3fTQo1mFCYZR5CFYIQS0yKspXbxxOPz9a+RxSXIF1/QTyXBY ddnq5u20I7ge2Qjb78UCbIqOkqbsjXep+dMk5La4MqdApuR7FaMQKqZzeGIKQ98X /mIHEp9DM17lAWS/GUrsI6N67/ythlslcYxA3JZNjn4OhkZVYERf8tetPiqKoS8H 5qif8W8FLNER/UhNbMkw0uN/Hh85lVYRrlhXH6+LufZORlysOvDl36AiiTL0ya3Z vpYnqieEAxKwKfrmDsguXOAdA4/Fg==
X-ME-Sender: <xms:uRJXX1ZC_cQR0PRVhPITYQ7eW5iiiUSOUMZLt6B-rvOM2hgi7B2xMg> <xme:uRJXX8aerGwWFFfIXAb-P_AyJuSi47eNXVPsJE5UeI6P4r0yHMo_cmj3ZFUbJd44m iDJNRgbaTEEd30Fww>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehuddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefhfegfffgffduhfefieetieduudejgfehheduffdvfeekvedtffeifeevkedv ieenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphifghdrohhrghdpmhhnoh htrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:uRJXX3_WDWb7_yAldov6br5bb2ltCgpM_tLHXNs9n41rls5aAuiuxw> <xmx:uRJXXzrakQZGRa9KkOuFUCa9XpBplohtkpYY2TOzPmjvXJf8IjBtVg> <xmx:uRJXXwrL5Ys-cGJUNo1KbPrJmJqSJYF-qVMdDruunQTPZ5hwaQKkkQ> <xmx:uhJXX31v9wydunWz_QyJvhiibyj9FdALTgcvB40USA5Wth97xPpqOw>
Received: from [] ( []) by (Postfix) with ESMTPA id E93F1328005D; Tue, 8 Sep 2020 01:12:24 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 8 Sep 2020 15:12:20 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1kFVvs-0001Wm-EL 94346b14ff4f5c33b9952cea8805d2d8
Subject: Re: New precondition fields and caching
Archived-At: <>
X-Mailing-List: <> archive/latest/38034
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 7 Sep 2020, at 4:31 pm, Martin Thomson <> wrote:
> On Mon, Sep 7, 2020, at 16:25, Mark Nottingham wrote:
>>> Assuming that interpretation is valid, how is this reconciled with existing uses of validation?  If-None-Match and If-Modified-Since specifically, which never in practice get recorded in Vary (at least not as far as I can tell).  Is it that we effectively bless these fields and require caches to understand them?
>> Yes. You effectively need to introduce a new protocol version to 
>> introduce a new precondition, if you want to make its handling 
>> mandatory. Designing them so that ignoring the precondition doesn't 
>> break anything is the only workaround. They are evaluated completely 
>> separately from conneg.
> Shouldn't the specification say that explicitly?

>>> Separately:
>>> The guidance for new fields suggests that definitions should consider where those fields are applicable.  The current semantics draft just describes each of the existing preconditions as "request header fields", while avoiding being definitional.  There is no text that says addresses the question of where they appear directly, even generic text.  That doesn't seem especially explicit, but is that enough?
>> Can you link to where you're talking about?
> says:
>> A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource. 
> It says "request header fields" here and in the definition of each, but it doesn't really say that these fields are only valid when in request headers anywhere that I can see.

I think we use 'request header fields', 'response header fields' and other permutations pretty consistently. Would it address your concern if we made <> a bit more explicit (i.e., included 'request' and 'response' as limiting modifiers)?


Mark Nottingham