Re: New precondition fields and caching

Martin Thomson <mt@lowentropy.net> Tue, 08 September 2020 09:34 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC023A11D1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 8 Sep 2020 02:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=czqdb7du; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CxQPuAKX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7_deOgJN9xJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 8 Sep 2020 02:34:46 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106883A11C4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 8 Sep 2020 02:34:24 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kFZyu-0007mE-U8 for ietf-http-wg-dist@listhub.w3.org; Tue, 08 Sep 2020 09:32:05 +0000
Resent-Date: Tue, 08 Sep 2020 09:32:04 +0000
Resent-Message-Id: <E1kFZyu-0007mE-U8@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1kFZyr-0007Wp-OH for ietf-http-wg@listhub.w3.org; Tue, 08 Sep 2020 09:32:01 +0000
Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1kFZyp-0002BA-QC for ietf-http-wg@w3.org; Tue, 08 Sep 2020 09:32:01 +0000
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 279655C0056 for <ietf-http-wg@w3.org>; Tue, 8 Sep 2020 05:31:48 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Tue, 08 Sep 2020 05:31:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=kaf8m9EW0PRA3NZKTl6krGlLZfOCSsO slgIGQRMVygE=; b=czqdb7duvp+ccxoap4I3dtVIy8HDO2+vijQ3GCnH2scd38L Tf+15OuTf5YKKsGGtlHM94OMk0gefhq6NjVaxjDjmzG404RaMxUwNsbcyE9Uq+lx lL1bkAVquWaJIrAbDupaBcCGIffxlE+v5LDNDV6b0RC6N70HeACf5CLtCcYgUECH lon0f4ZgqKU8g6n8nQQOSRhXI6gsGVZZDNNdkQbh5jNfADA21F3YTCNketuw9Vzd NuJ5EHSQf7F8Trl82FWPaj6JM0QxMYAw8fNE4JVBqaFQfRlOJoZ0pltN4wfqV8Km EYTZD0YkFxJmGzyUDJVZv8awGyRzbAbFaw+ajHw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=kaf8m9 EW0PRA3NZKTl6krGlLZfOCSsOslgIGQRMVygE=; b=CxQPuAKXOzYEsHUuIohsGt 2GxxeVjvr82RwzfAZ6qedje+Vv6J14yaO+kT9liE9QlpmBcU5tuErQ+BnhAHeoWN o80O+Ej4nN/szdvl8d3BQxO5TzAfNeUXDGfFyv+8lwRt605FyxZBPMk9x2JNKhZl 6l/DG3DyuDR3jEYyJqj2KOzbY7FCQB+qRx5kcE1I8S5NZSoLCQvsX9HQDBESkEjW ddciF949cTOtX4dFtQHjNO9BLzztPRLKMVTh7zcSptSyJPeytNszD3C/FfYXbMTF rE5cPLHTaPUiB/oXiE1PIEoYRJqOC0+Vb7IofBF9/mXtC6OOlOYGa1h4TIIXDZ9Q ==
X-ME-Sender: <xms:g09XX0-7XQBZqw2q4ZpjIsgJ4xGb6svtE7xHoFste1JzkILLIGDZ1w> <xme:g09XX8vW-9Ru9lUdm7P9Ob47ofczrWjebb7WqQgCRTjGNa-KLVrwnWmOamNyZ_J-f 8mq0je6lyMFceMnkQI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehfecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepueegteeiveduheffiefgfeehhe ffjeffledvkeduleeigfduuefggeduffduudetnecuffhomhgrihhnpehgihhthhhusgdr tghomhdphhhtthhpfihgrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:g09XX6AuufYvklRfoG5EdBuHpnQfFpjglEoV45zzpRih2segYbTS4g> <xmx:g09XX0cGIG0k4BZZcw2FZxRlVQneJILit2vc3zaV2ufwdaMLEEtVcg> <xmx:g09XX5M6_tNEVbGlntzar88ZwAh2mmmohU2xpaqt8gNKnWCxXs2iKg> <xmx:hE9XX_agJvOAhyhLxNoT9qBisIc69ClZiUg_pcZzuTKzUu620toDcQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2A05200DF; Tue, 8 Sep 2020 05:31:47 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <eaf03bb1-02dd-4cf5-9f7d-7f9424d0af92@www.fastmail.com>
In-Reply-To: <3F69CA61-C9D2-40C0-964C-D06FB8E38F7D@mnot.net>
References: <7c1e8964-1a4b-42e6-8af1-fc7a4e43ce14@www.fastmail.com> <A33B6430-22A0-4FAB-82BC-85D86A5FBC6D@mnot.net> <48205d24-46b5-488d-b13b-a0a7d005a556@www.fastmail.com> <3F69CA61-C9D2-40C0-964C-D06FB8E38F7D@mnot.net>
Date: Tue, 08 Sep 2020 19:31:27 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Content-Type: text/plain
Received-SPF: pass client-ip=66.111.4.25; envelope-from=mt@lowentropy.net; helo=out1-smtp.messagingengine.com
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: mimas.w3.org 1kFZyp-0002BA-QC 4ec057833849f013177e660bb4dd5f87
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New precondition fields and caching
Archived-At: <https://www.w3.org/mid/eaf03bb1-02dd-4cf5-9f7d-7f9424d0af92@www.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38035
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


On Tue, Sep 8, 2020, at 15:12, Mark Nottingham wrote:
> 
> 
> > On 7 Sep 2020, at 4:31 pm, Martin Thomson <mt@lowentropy.net> 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?
> 
> https://github.com/httpwg/http-core/issues/448

Thanks. 

> I think we use 'request header fields', 'response header fields' and 
> other permutations pretty consistently. Would it address your concern 
> if we made 
> <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.and.trailer.fields> a bit more explicit (i.e., included 'request' and 'response' as limiting modifiers)?

That might help. I think that my concern isn't that serious when I look again though. The definition is definitely implicit, in that you say these are header fields in a section called request fields.

You already have "We refer to some named fields specifically as a "header field" when they are only allowed to be sent in the header section."  That is quite clear there, but the use of that is less so with the phrasing chosen. So whatever you think works best.