Re: New precondition fields and caching

Martin Thomson <> Mon, 07 September 2020 06:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EE593A15B5 for <>; Sun, 6 Sep 2020 23:32:25 -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=j2eamHfw; dkim=pass (2048-bit key) header.b=njYOtDyC
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BlDisvPN55v0 for <>; Sun, 6 Sep 2020 23:32:23 -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 BB32C3A15B4 for <>; Sun, 6 Sep 2020 23:32:23 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kFAhH-0005TJ-1E for; Mon, 07 Sep 2020 06:32:11 +0000
Resent-Date: Mon, 07 Sep 2020 06:32:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFAhF-0005SY-St for; Mon, 07 Sep 2020 06:32:09 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFAhE-00027V-5w for; Mon, 07 Sep 2020 06:32:09 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 6FFEA5C0054; Mon, 7 Sep 2020 02:31:57 -0400 (EDT)
Received: from imap10 ([]) by compute2.internal (MEProxy); Mon, 07 Sep 2020 02:31:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=iIwagMpzK/l9Z2Xths99MmghyIMu WniIMryhOtW/YrM=; b=j2eamHfwMtLcMJmX/FDSpNZzjysKKFMWBDmH26DcOBwB f42qJ3LNZqE3R/BvbnCqMNjyHhaqBhidTqYK3HGg+y4MVZiDXPdkJgQPQT6MW5L4 jJuivNhrIypH0lLzg9bjaf3IXQiWrmYFIpzPU/ZI7KhYsQmiaUs6INPN9Z4Cj4Vo IjoQCgHpAnmNQ+fRkkqfh4afHNl6rWY4RtHvMUkyEyGvum3HZaqxT0JxTHm5bQ4v kvP7MlNHuhY1SwMCp2LabL0cMmPkGgscsWy7TeM1nlyNtJMdMlT+r8121BWVwB0I /oaikdRtmvvFuEYpKava4h6dCy9b4Y1oaQLZN34+sg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=iIwagM pzK/l9Z2Xths99MmghyIMuWniIMryhOtW/YrM=; b=njYOtDyCkS/3AvM90oMlRw g2KBPE46gxtRC/Tn3FXTJsBW8xHF8LTNVEWOeObFs0mecI8xWufkSDGDctSEZOWF sE8pEHz/vbTz1hd5QsbUeFoo9W9QE1ZjAETDHv3Ywe1UGg0KusqqHFMSZgaG0A9k 3G3IjH7twGA0eVq0o1FMS3s6eJzRYMw9NsiL1ApZGjE7wyHxCX4oSnxYgUTlHI48 THA4Zdmnobbg/OEPgCTblaigmCeHCIGTuOc7jqmS3M8kokj8k2AN33nksxy9V5/K nw4TF3Vkel3IGz5PIFHF6oOnoRqRqu4/bOCTkY7LHVfDrVAbn3WJS4xYxfAZZmQg ==
X-ME-Sender: <xms:3dNVX8qNQYq_YQ-u0y9sTKzLjZK0UtjPF5C3BZpG45_HjvzjMWK3pg> <xme:3dNVXyr3eu1wPMXFY38dOFq2MCEIf5vqiP398NR8W7ukYmS694rQfxSPEkI6FmopU qkydkmYjNHttpE1M1c>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnheptdelgeeigfejkeduleekgfffgfevudekudetgfekvedvhfduiefh veehheeuffetnecuffhomhgrihhnpehhthhtphifghdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvght
X-ME-Proxy: <xmx:3dNVXxNRg9WcVIEb1_WRCAFrM4-aVWf-DSZTtBUajbUkDsDh1eHCXg> <xmx:3dNVXz4DKGBiOme_WE4rOPlm8e-dTDNJ5cbdJ2HLbayvU8c3Tm4Nmg> <xmx:3dNVX77ZXuHnPNfVLkThF8wYNZ7WFFKodJ9CO0dCpO96czGeQGsMmQ> <xmx:3dNVX0UlMzsjtiCOj6eMgWhqEJ0QchO9nZcQt5kgr4_nYE9eE7ge6Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01B6620072; Mon, 7 Sep 2020 02:31:57 -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: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 07 Sep 2020 16:31:36 +1000
From: "Martin Thomson" <>
To: "Mark Nottingham" <>
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_H3=-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: 1kFAhE-00027V-5w d1ecfed0c02aa30b2acd1cf028ee891a
Subject: Re: New precondition fields and caching
Archived-At: <>
X-Mailing-List: <> archive/latest/38020
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.