From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Thu Mar 14 05:06:04 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 851ABC14F68A for ; Thu, 14 Mar 2024 05:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.855 X-Spam-Level: X-Spam-Status: No, score=-7.855 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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="o84rkgSd"; dkim=pass (2048-bit key) header.d=w3.org header.b="pBqBlWFR"; dkim=pass (2048-bit key) header.d=gmail.com header.b="lmn6EQW2" 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 derkG-eXR2Yn for ; Thu, 14 Mar 2024 05:06:00 -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 91B8FC14F5F4 for ; Thu, 14 Mar 2024 05:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=swFXsAVHt1VEHZmZGh8ykyoPt0Wgjntj5ErAu7oOU6A=; b=o84rkgSdFW/bdhsTdnX9DPldpm vIn4lmfvXvg+l+A7F0GzzVNGMSHWHc0S4elmsDeEuqtChopspll3ur0x4RxtIzhIB6MXHS6s2mIjj 5AcFxk/nyVmWx61SYGgqWfYCc6SCJ5r/noGrqA4WmEuXkqhE5UYQNWyk1A6HHWk5PAyYuRJyavbs6 MA87292Ez95nnPicKFK8tsLHmyf3mZvHedpeogTcJSI7bO/lgsmmjJGvYcJD+Q58Zn4kST11gAlgR rzjGqBuzwyuPrGeu5by/B483HQeNmS0AgEIjMVwA0UJ64LzfHIr3N+s1glDGP7W9a7nrEJaxWn3wq DFFNUgJQ==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rkjo4-007dc3-CZ for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Mar 2024 12:03:32 +0000 Resent-Date: Thu, 14 Mar 2024 12:03:32 +0000 Resent-Message-Id: Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rkjo2-007dZr-0m for ietf-http-wg@listhub.w3.org; Thu, 14 Mar 2024 12:03:30 +0000 Received: from pan.w3.org ([3.222.182.102]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rkh4u-007Fjw-Nq for ietf-http-wg@listhub.w3.org; Thu, 14 Mar 2024 09:08:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=swFXsAVHt1VEHZmZGh8ykyoPt0Wgjntj5ErAu7oOU6A=; t=1710407324; x=1711271324; b=pBqBlWFRHtU+pILPLkAJB9e+CIPqzwlPiJt7Cx8jWq/hFAv5Mk6gwUahoYl2dYzdzMTuXbaiSU7 GpHD5ljNeanvcHUK86r3WL71IPm2s+bBxKHbG6VrpVM07cAVYFUtVLUfcyfi0izmm5jKBufqynEhe SS9Wo4qzLGl/CZF5+XvMQp7JkVywMfy8iMzxr4oIa2HIvuNZfzIEYnYwIw6fkBtHP8u+FuC3kb4zt WkkUqrHIC8XYdWtgLTPFcp5sb2HAiFpYmKOSl4ubw/AOzV/GWyRTqkbd6EqPheu90l1lg3kVyRXd/ VfQlcBu0b4qTJrQNqLf3RcxVd1KQ+h8SME2g==; Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2607:f8b0:4864:20::32f as permitted sender) client-ip=2607:f8b0:4864:20::32f; envelope-from=marx.robin@gmail.com; helo=mail-ot1-x32f.google.com; Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1rkh4t-00B9pP-31 for ietf-http-wg@w3.org; Thu, 14 Mar 2024 09:08:44 +0000 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6e4e8687a96so250304a34.1 for ; Thu, 14 Mar 2024 02:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710407320; x=1711012120; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=swFXsAVHt1VEHZmZGh8ykyoPt0Wgjntj5ErAu7oOU6A=; b=lmn6EQW285UiMJM0wRvLhq6KaAo8RRXxWZqEayjsBHucLCqaDkGMH4ybGll/+jnA2D QeodCyCvnkhqAEfs5Vbke4UvHx9sayNwPMtxrDu6EFUZx4zoJp0Z1tDf7ty2J7GLr93R wnYyBImKQAAY+HBJ/iOeMOhKVIbzTqY2cCQ7EIoRi1Uq2NqnNshkOgp9NPsb9aFS3pdh NbBy9Y73/fmmZL1ZxEK6BMZaWHHS0V1YAw0wFi7kcJBb9sAbiAYpw7mqy9EH6ttMsf/O NvmgIqxDL8pnM7qoFN9YU1wx2wSu8vsRAwMHZisPWedrhK4M2ROKAJoGMlC0VmQNJeod ndrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710407320; x=1711012120; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=swFXsAVHt1VEHZmZGh8ykyoPt0Wgjntj5ErAu7oOU6A=; b=mWGdbSVK5oeJg/gj+ZkecwDXxmu3YkPpBxKGkYCC+mLhnkHGGqHw3G3LIVTsTw6Tgo YdVXPP9U3NW/2uWtx/MLmXcWRUZy7YaIR1O7/ztwuTCyY8pgn5IL06H+Pqs6BnZ9Ah0c qqxYAhiLEmN02JNjuA9Ptla64KGVtoXVd6u0v7GD7i1w6fZB4GrAHiMeAoOju4+DmqNG hdQOOfTdcLZ8maTxUD0DAUKkQytzKPWM0TAMs8xPQd9rmr8YLWCfTguQATru4eF21Ob4 JY/ofx7Z+dMFqgVrD19EhV1K5olv/Vd2+p2O/tWPiJ+q5d6Xeg9vSZXXubYmm/MFrCiT 73QQ== X-Forwarded-Encrypted: i=1; AJvYcCUB/Ety8Mw58t+VRgdQVjQqttqJZtbfmgtRcNSKSrivoJUUPBX4J4wgNTM674sLyyygEC+wVbeWaQqoBC58uesIZiEK X-Gm-Message-State: AOJu0YxqTtP95fT4NQ6ic2WBT2xrIhF7EXneYqhASAeMd3ozkgm4De8r J4LDvYAW7TExFa/duH8uVW+lNGxqmxU6Zkp5UYRDe5b67LSmsLS2yqZd8SY5d/VyvKnJmJrK5OL w+0FDuoPfDo6MJsPIyB+7SAaXfFZ5bv5RcOA= X-Google-Smtp-Source: AGHT+IEbud0fiRckj3WW9la7dwmquYWm3qCgp/9I0qSF4+6vveZ1QBdvAlWwMKLOkdj5pcOIHnCXSnMXZw7gguwjbp4= X-Received: by 2002:a9d:3e5e:0:b0:6e5:3b9:5dad with SMTP id h30-20020a9d3e5e000000b006e503b95dadmr39823otg.24.1710407320167; Thu, 14 Mar 2024 02:08:40 -0700 (PDT) MIME-Version: 1.0 References: <9730212B-8166-4A8C-BB79-77939B1E3DBB@mnot.net> In-Reply-To: <9730212B-8166-4A8C-BB79-77939B1E3DBB@mnot.net> From: Robin Marx Date: Thu, 14 Mar 2024 10:08:28 +0100 Message-ID: To: Mark Nottingham Cc: Jeremy Roman , ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="000000000000bd6ba906139b3c1f" X-W3C-Hub-DKIM-Status: validation passed: (address=marx.robin@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-4.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: pan.w3.org 1rkh4t-00B9pP-31 bfe37591b932e678001aea2382e2a003 X-caa-id: 48f8dccbe7 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/51879 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: --000000000000bd6ba906139b3c1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jeremy, 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. 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 (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. Potentially we might prepare something to present at IETF 120 to help further discussion / bring it to the wider wg's attention? With best regards, Robin On Thu, Mar 14, 2024 at 4:18=E2=80=AFAM Mark Nottingham wro= te: > Personally, I'm supportive, but that's probably not surprising :) > > > > On 21 Feb 2024, at 13:08, Jeremy Roman wrote: > > > > Hello HTTPWG: > > > > 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 th= ey > 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. > > > > Fundamentally it seems like something less strict than "Vary: Cookie" i= s > 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 c= an > be configured to work this way), so HTTP WG seems like potentially the > right venue to discuss this. > > > > 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 wh= at > I'm looking at right now, but at this moment we're not yet committed to a > particular solution. > > > > What do you all think? > > -- > Mark Nottingham https://www.mnot.net/ > > > --=20 Marx Robin +32 (0)497 72 86 94 --000000000000bd6ba906139b3c1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jeremy,

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.=C2=A0<= /div>

We were originally also looking mostly at the Avai= lability Hints draft, but see there's also ongoing work around "ca= che groups" (i.e.,=C2=A0https://www.ietf.org/archive/id/draft= -ietf-httpbis-cache-groups-01.html).
This seems like a potent= ial alternative; if affected pages for example by default get a cache-group= of "not-logged-in" and then the server sends=C2=A0Cache-Group-In= validation: "not-logged-in" upon successful login, this might giv= e the expected behaviour=C2=A0
(though, arguably, in a workaround= -y way maybe? and it seems some normative language in the current draft may= be isn't optimal for this use case).
It might also run into s= imilar performance issues as we've seen with Clear-Site-Data: "cac= he" (see=C2=A0https://calendar.perfplanet.com/2023/rli/#clear_site_d= ata_header), but still, a potential alternative to consider.
=
Potentially we might prepare something to present at IETF 12= 0 to help further discussion / bring it to the wider wg's attention?

With best regards,
Robin


On Thu, Mar 14, 2024 at 4:18=E2=80=AFAM Mark Nottingham <mnot@mnot.net> wrote:
Personally, I'm supportive, but that&= #39;s probably not surprising :)


> On 21 Feb 2024, at 13:08, Jeremy Roman <jbroman@chromium.org> wrote:
>
> Hello HTTPWG:
>
> I'm working on speculative loading in Google Chrome (most salientl= y, prefetch of documents for navigation) and looking at ways to address the= potential problem of prefetched resources becoming "stale" by th= e time they are used due to the user logging in or out (or similar state ch= anges), in response to developer feedback. Workarounds are possible but som= ewhat awkward.
>
> Fundamentally it seems like something less strict than "Vary: Coo= kie" is called for, which would let the client know which cookie value= s, if changed, invalidate the cached resource. The semantics of this seem p= otentially 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 righ= t venue to discuss this.
>
> Mark Nottingham's Cookie-Indices proposal (part of HTTP Availabili= ty Hints) seems likely to address the problem and ought to be implementable= (I'm prototyping it in Chromium's prefetch cache, at least), so th= at's what I'm looking at right now, but at this moment we're no= t yet committed to a particular solution.
>
> What do you all think?

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/




--
Marx Robin
+32 (0)497 72 86 94
--000000000000bd6ba906139b3c1f--