Re: New precondition fields and caching

Mark Nottingham <> Mon, 07 September 2020 06:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D0343A15AF for <>; Sun, 6 Sep 2020 23:28:26 -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=jZpPm+oZ; dkim=pass (2048-bit key) header.b=j4IAkhwf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HfdE61S3hkKz for <>; Sun, 6 Sep 2020 23:28:24 -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 8424F3A15AD for <>; Sun, 6 Sep 2020 23:28:24 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kFAbU-0004E6-4l for; Mon, 07 Sep 2020 06:26:12 +0000
Resent-Date: Mon, 07 Sep 2020 06:26:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFAbP-0004DK-IJ for; Mon, 07 Sep 2020 06:26:10 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFAbJ-0001zI-Nb for; Mon, 07 Sep 2020 06:26:07 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id F11115E3; Mon, 7 Sep 2020 02:25:46 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Mon, 07 Sep 2020 02:25:47 -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 5DU1PpsyY6BYIK0gr6bkJieDa2zex9IsGmJ9/wntZ8=; b=jZpPm+oZUXqSM4ogw 9eUcbXMzLS9hHx0vBc+Lkg0iH/qc3b+vMzGKoswRobrw7egFxj26+jUc49J5uKSm LqvyOuoX9VJSZxk4gIKiTtZmkzt/D3gLbWM8R99wE2igCx1v4sZk1F7s/DDK9fc+ WCqhGLMBcZmhnVrp8aR0qnld+MX3ZulbPjPKPgoYbV3sRPYlbAM/k320i8ntocv9 sLEdQaXX916QgxA61zBgc2B7GA+gCEM7MOrOdd9vxnnt6R6BQ8JVzm1vs3pJqMoR fIRWOF7tjDx3QB2SeGe55vaa3HIwrNENepFw0wIatRQJaL8JZX5r+pX+jmotBqkB WqAlw==
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=L5DU1PpsyY6BYIK0gr6bkJieDa2zex9IsGmJ9/wnt Z8=; b=j4IAkhwfa2itjLgMGGCNxgRSVWASZgo3EizZUegtbfnde+RnOZbUXJ4QY ctSii/tjhMr+RE0kXo5oF41FQkbnUcGrza/ZZR44mjEWepKWLEpbnEbVXJrMuN3g JvNjrHH8QCGAIQnN+TY30iTq4fg3eUCSPBrfc3o3x+MEMuOWwMKdGEcCNWOz8VeK 5H5kOL8yZqRnzMSy4B2/MEq0gbr3Gtp/GvjxLWp2JFED5cqr5jxPlG114XM40/qY 2dCCsMzbqlF7lIqeZXGVD/3a0OcjHQ0FAJV25MKTQ9gLvAJ0L7w1rJn5dRuELrQL f5KAem578f8ifWhTQWICdN8RJCNgw==
X-ME-Sender: <xms:adJVXyIoO1vupYamyw6md8EiWiFZIbO3d8D5MOkTrE1lvMAUdcp-KQ> <xme:adJVX6K-jMHpUKv7JDUupgftLHIbQNZtmJsdqpX4oRigEIDQftdQE18FbaqjnbPO4 ZHApSg-JxsDRcXwjw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegledgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:adJVXysP6wyFkjxmFel1vypgKrWliEKJEc9g5-sNUG-BDzlkwNJpJw> <xmx:adJVX3aDPTrx8S1UrJZ-wzJKzflkFuW5aWXMlo3bsiDT-dKHC6sNbw> <xmx:adJVX5bBWNFuTmcnLl7rpiofFPtkyICDvV8B13h3OTh3uJMK3pT_pg> <xmx:atJVX4krJv7pbNSo1hhNdc8M_WSjFnUKsMC_AAxN6repmfXJdN_rNg>
Received: from [] ( []) by (Postfix) with ESMTPA id DF5B1328005D; Mon, 7 Sep 2020 02:25:44 -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: Mon, 7 Sep 2020 16:25:41 +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_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: 1kFAbJ-0001zI-Nb 5bddc19a4952d97e7f4f12bb8b429a6c
Subject: Re: New precondition fields and caching
Archived-At: <>
X-Mailing-List: <> archive/latest/38019
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 7 Sep 2020, at 3:43 pm, Martin Thomson <> wrote:
> 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?

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.

> 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?

Mark Nottingham