New precondition fields and caching

Martin Thomson <> Mon, 07 September 2020 05:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEB023A154F for <>; Sun, 6 Sep 2020 22:46:57 -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=HZVlHiDS; dkim=pass (2048-bit key) header.b=BfxoDz9j
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cGSS_EC5TJ8v for <>; Sun, 6 Sep 2020 22:46:56 -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 678C03A1550 for <>; Sun, 6 Sep 2020 22:46:55 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kF9x6-0005QA-3r for; Mon, 07 Sep 2020 05:44:28 +0000
Resent-Date: Mon, 07 Sep 2020 05:44:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kF9x2-0005PJ-3u for; Mon, 07 Sep 2020 05:44:24 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kF9wv-0002AP-A0 for; Mon, 07 Sep 2020 05:44:18 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 68F7D2DC for <>; Mon, 7 Sep 2020 01:44:04 -0400 (EDT)
Received: from imap10 ([]) by compute2.internal (MEProxy); Mon, 07 Sep 2020 01:44:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=3tLPbOFgVY2rsTAGgRAz+OAo7XioKoVYFW2Dgdy8tsY=; b=HZVlHiDS LL9eX5v2chFfNq6MnQa3rpNLijuiF4lP4QXvnyJZhbbwSr7CjTn+8TqS5sbW2eFY azB9rhhXuu6XTuGA5Rkq7kRBPOoPvzqF37Zkd8IehgDYVYfxeaS12ljI1dkLmiZD PKbW6PIws4gXmmLrR6y0hnG2P1IQOjDO1BIXJrZc4Hy1Iuia6aFeB5jJ2W8wzNtM wn5Ps6FFD8sz41nSHPtJR1G4/Ib5JL2TKaGelmFjD969rTcZDr0PsRTrKVJqe0vH bJu9Qv7OeF3XTqfABkvSGNCxZBx45SqJ9gJiPrVgU/q6NbGllyHS948r+eCGYBRP eeA0sJMWpcPkOA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=3tLPbOFgVY2rsTAGgRAz+OAo7XioK oVYFW2Dgdy8tsY=; b=BfxoDz9jklFUC+MTVMrST1qM97+5eW+eUvqUIC+BW1qv0 mEX5nG9S8iMxWE/BuiUZ8cs/O1z3pn7N6uJ7AqTmrks5IhExb3WgD3vXpZBWrL9I ntpvvfVLDMsrRzwK1S3aQxDmas6w0K9o5DYGgXMH6km9QpJO+O2zR0oSwleeWPzw 6mGN0GwwMTp6kZ7vkmhf1SKnljC9u4kxKxi3pCVyrKc8jxEXI6AQ9hhAKIFjvhwS TI0fjQyW8Ak+rF2RSKMPM/7/HrXClmvYj88RoiPF8BqD0gntqkoKYAT/zHX99qa8 Ku/c41DSFs2aKXtSOm8SV+hk2AhGU4KQ4HsblfVaw==
X-ME-Sender: <xms:o8hVXxS-HSxsOKXqBz1ZLtMqNTMuSSIkRWyFLolHN1EFobj7oRsXyg> <xme:o8hVX6wC1ltA_L3JSt83hcFsDNg_lE25jb-27PfyQY8muN5iCyn4r1JzXWzJVkUJQ EgIjrEFa8vpoLL68c4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegledggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeevgfdutdfgjeefudeuheekhe ekudeugeehfeegveekkeegleevveffueduffehheenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:o8hVX20Ddvb10DW5_tDioQ5RhHYaag2h8EERk4lvQu4mG5nYsOqx2w> <xmx:o8hVX5DPsuomMQXdiwRRU-UwG3skXYQGsUxlrsGjCPHCi9y9uzjBOQ> <xmx:o8hVX6iEoQm-1EIPvHO3W889XhmZB1wWGH3UtxVD5BIW9EeMLsZLtw> <xmx:pMhVX1tXGJpK5zB5H8e2lYnqX6XeKSB29T84-Gzf5rbvjG0sExIKJA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE744200FC; Mon, 7 Sep 2020 01:44:03 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <>
Date: Mon, 07 Sep 2020 15:43:43 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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: 1kF9wv-0002AP-A0 fb321551b5cdd5e6d4da2c11f6d412c0
Subject: New precondition fields and caching
Archived-At: <>
X-Mailing-List: <> archive/latest/38018
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'm trying to understand whether HTTP can be extended with new preconditions.  I've so many questions.

If-None-Digest can be used for validation, so it currently defines that 304 (Not Modified) applies when a GET or HEAD request fails the precondition.  However, that seems fraught in ways I didn't originally anticipate.

Thinking more generally, the 412 (Precondition Failed) status code can be marked explicitly cacheable, but for this to work the server would need to indicate that all responses Vary based on the preconditions that might fail.  That includes not just the 412 status code, but other status codes.  That requirement to include the new precondition in Vary extends to 2xx responses, which could then vary based on the conditional request header field.  

For example, a request contains a precondition `On: Wednesday` (a bad example perhaps) which ensures that preconditions fail 6 of 7 days of the week.  For this request, both 2xx responses (on Wednesdays) and 412 responses require `Vary: On`.  Without Vary, an intermediary that receives a new precondition `On: Wednesday` could use a cached response and generate a 200 response based on its ignorance of this being a precondition even when the precondition would fail at the origin server.

If the same applied to If-None-Match, a whole lot would break.

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?


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?