From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Thu Mar 14 22:12:57 2024 Return-Path: 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 5BA08C14F691 for ; Thu, 14 Mar 2024 22:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="UZXw43Ro"; dkim=pass (2048-bit key) header.d=w3.org header.b="h0tRyAb/"; dkim=pass (2048-bit key) header.d=mnot.net header.b="MFQeaNpN"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="W1D82vVZ" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bhb2TfZnUvo for ; Thu, 14 Mar 2024 22:12:52 -0700 (PDT) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E39C14F69E for ; Thu, 14 Mar 2024 22:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:To:References:Message-Id:Cc:Date:In-Reply-To:From: Mime-Version:Content-Type:Reply-To; bh=WtOE6XiXDahB9JAi8QOTzK1dD8gQ0+kdoDPCm0HEtzI=; b=UZXw43RoMP6ne8lvzQBSuU17Wc mXy48h5w+hYpizTWFZnqdj8dUKtEKiRdXYbhRDJw0x4H19XE3Mq12R/Ck+1m3gl2KsS0Br3u0bgmP SuwbxZiy6sAVzsSiMAf1YitGlt0vMkN5hcLOO/T8oTUN8XClt9n/luGay3lww/0RpS4C5x5JQd8vl F47QufCGbuUEkJ7MtK0jlEEvyA+jWKWdiW6MtIOp+usNx87BOCElxxrlJJphy3Oe6dAfPCGiqnoXO Z/78YbkjNPkKBGSLbnNKqCsWA2sHitF18yI2faV/7dmjxP5uMlYi3tEpRt8nB/Sco9tJgG/InsSMa Y1Og+Cwg==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rkzpC-009rHk-T6 for ietf-http-wg-dist@listhub.w3.org; Fri, 15 Mar 2024 05:09:46 +0000 Resent-Date: Fri, 15 Mar 2024 05:09:46 +0000 Resent-Message-Id: Received: from puck.w3.org ([34.196.82.207]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rkzp8-009rGd-4i for ietf-http-wg@listhub.w3.org; Fri, 15 Mar 2024 05:09:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: Mime-Version:Content-Type:Reply-To; bh=WtOE6XiXDahB9JAi8QOTzK1dD8gQ0+kdoDPCm0HEtzI=; t=1710479382; x=1711343382; b=h0tRyAb/dzuyhc/p5H14C1rZGjHSVT3ANjxWMXJIgJbJFTVHiiRuyZ17a+coWovZfIsMYX1CFSQ Z5T8gN3AL3MKt3LYzuhsyxlMT2tLPgN2zht1Eu0WYh8NEv0l57DdlWMlHHdvWrG53kIRIObhZ23o5 ZOX8TNOCr/sEkzfKT8EcvrggenMx68KEGSRzfvpnNj/8BP4p1w/ITUyrx1LVHqUDjqNe2xm3ndb53 n7u9tWDunh89pxiv+ooAC2KMt5WDar6Q5JkWUgkfAKMau6Y39CTebWNCDGsAhWQ9tazp9saDXWjEE 8a3I+fDmTtsFrRc4PwIiO0FPfemagcoAsnaA==; Received-SPF: pass (puck.w3.org: domain of mnot.net designates 103.168.172.156 as permitted sender) client-ip=103.168.172.156; envelope-from=mnot@mnot.net; helo=fhigh5-smtp.messagingengine.com; Received: from fhigh5-smtp.messagingengine.com ([103.168.172.156]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rkzp7-008Agq-0B for ietf-http-wg@w3.org; Fri, 15 Mar 2024 05:09:41 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id C170511400D0; Fri, 15 Mar 2024 01:09:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 15 Mar 2024 01:09:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1710479377; x=1710565777; bh=WtOE6XiXDahB9JAi8QOTzK1dD8gQ0+kdoDPCm0HEtzI=; b= MFQeaNpNH/wFdqXbVe2GLQWfSIF9dRAerzCkHKAhB0QP+61HEZsfMkI3zuiF1Q/7 4hb2DZl3B/Gr1WsCKO5UWKUiMdyWN+WCxN0bBd0oOJMr/fJKRj9HmKcG/PNNnSdj 2yNXX4rOEQl2DzCWdI/+lfGYQUkoJ16V+7YVezrsD/C/yQbA46yvc5MwwxWiKzm2 r+GBVG/vpaa5/Anf1ph0uliaFw6XsGnHbUYAa89FkdDSF7j1pAX7noyQqCmoK/e5 q495ajXlFqVZG8R7eOQPog0ONItVKyxR8vIR5ou0UlMZNAE5DCijhkyQ1udSWn1T 1yYOVTBD8nbCgkuuJNJWHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1710479377; x= 1710565777; bh=WtOE6XiXDahB9JAi8QOTzK1dD8gQ0+kdoDPCm0HEtzI=; b=W 1D82vVZtEzJ1nYuR0JPGrSVAYpo8JxKO00gUkNtZKU1/LR9cpQxjlb+2+ddmz/e/ TkUI+qaw4+wBO4MwUcpiz9UWSoG0LKXV7EHaUOgHEh72Zn5hV7VK9HREHfqEuKv+ oZ0/yKmuExhpftIXDEOg8BravbHbK6g5NaEG6nQY2No1mypXe0OcnSnA5jiG9UK3 +jYgdG6ginvzmvz3bTc+E783ErX+UW0iogG0sjSytgbi7CL4vwU/zrTRbfoETIxr LUZ+qQ3Du8rCXGFTMljnxfgkF3N2AZzaEyqUUHweXY4ZevU45uTEpEbjTJKj9kr4 jRtSIJcx+raQCFhIYX/7Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrjeekgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjffevgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpedvgeegjeefgeegveduteekuddtheetvddvueeijeeugfevudejleefvdeuheeh veenucffohhmrghinhepihgvthhfrdhorhhgpdhpvghrfhhplhgrnhgvthdrtghomhdpmh hnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Feedback-ID: ie6694242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Mar 2024 01:09:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Mark Nottingham In-Reply-To: Date: Fri, 15 Mar 2024 16:09:31 +1100 Cc: Jeremy Roman , ietf-http-wg@w3.org Content-Transfer-Encoding: quoted-printable Message-Id: <92F71D70-F1B5-4186-ACDD-3FA1427A9607@mnot.net> References: <9730212B-8166-4A8C-BB79-77939B1E3DBB@mnot.net> To: Robin Marx X-Mailer: Apple Mail (2.3774.500.171.1.1) X-W3C-Hub-DKIM-Status: validation passed: (address=mnot@mnot.net domain=mnot.net), signature is good X-W3C-Hub-DKIM-Status: validation passed: (address=mnot@mnot.net domain=messagingengine.com), signature is good X-W3C-Hub-Spam-Status: No, score=-9.1 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, DMARC_PASS=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1rkzp7-008Agq-0B 2abf9408efa55d5123a82ee9a05f954c X-Original-To: ietf-http-wg@w3.org Subject: Re: Cache varying on particular cookies Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51881 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: Hey Robin, I don't think that cache groups are a good solution for this, because = they require a separate invalidation to be sent to the cache -- = requiring not only latency but also for the origin to know where the = cache is. The merit of availability hints in this situation is that all = of the necessary information is already available to the cache. Cheers, > On 14 Mar 2024, at 20:08, Robin Marx wrote: >=20 > Hello Jeremy, >=20 > I'm part of the team at Akamai behind the "awkward workarounds" post = you shared :) > We obviously also agree something like this is needed and would like = to collaborate both inside and outside of the IETF to further this.=20 >=20 > We were originally also looking mostly at the Availability Hints = draft, but see there's also ongoing work around "cache groups" (i.e., = https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-groups-01.html). > This seems like a potential alternative; if affected pages for example = by default get a cache-group of "not-logged-in" and then the server = sends Cache-Group-Invalidation: "not-logged-in" upon successful login, = this might give the expected behaviour=20 > (though, arguably, in a workaround-y way maybe? and it seems some = normative language in the current draft maybe isn't optimal for this use = case). > It might also run into similar performance issues as we've seen with = Clear-Site-Data: "cache" (see = https://calendar.perfplanet.com/2023/rli/#clear_site_data_header), but = still, a potential alternative to consider. >=20 > Potentially we might prepare something to present at IETF 120 to help = further discussion / bring it to the wider wg's attention? >=20 > With best regards, > Robin >=20 >=20 > On Thu, Mar 14, 2024 at 4:18=E2=80=AFAM Mark Nottingham = wrote: > Personally, I'm supportive, but that's probably not surprising :) >=20 >=20 > > On 21 Feb 2024, at 13:08, Jeremy Roman wrote: > >=20 > > Hello HTTPWG: > >=20 > > I'm working on speculative loading in Google Chrome (most saliently, = prefetch of documents for navigation) and looking at ways to address the = potential problem of prefetched resources becoming "stale" by the time = they are used due to the user logging in or out (or similar state = changes), in response to developer feedback. Workarounds are possible = but somewhat awkward. > >=20 > > Fundamentally it seems like something less strict than "Vary: = Cookie" is called for, which would let the client know which cookie = values, if changed, invalidate the cached resource. The semantics of = this seem potentially useful for other kinds of cache (e.g., some = caching proxies can be configured to work this way), so HTTP WG seems = like potentially the right venue to discuss this. > >=20 > > Mark Nottingham's Cookie-Indices proposal (part of HTTP Availability = Hints) seems likely to address the problem and ought to be implementable = (I'm prototyping it in Chromium's prefetch cache, at least), so that's = what I'm looking at right now, but at this moment we're not yet = committed to a particular solution. > >=20 > > What do you all think? >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 > --=20 > Marx Robin > +32 (0)497 72 86 94 -- Mark Nottingham https://www.mnot.net/