Re: Collapsed requests and response freshness checks

Alex Rousskov <rousskov@measurement-factory.com> Mon, 19 February 2024 16:47 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@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 1048FC14F726 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Feb 2024 08:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.756
X-Spam-Level:
X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H3=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="UjF7WzQd"; dkim=pass (2048-bit key) header.d=w3.org header.b="Arph2z3W"
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 91mkFPJbbCnw for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 19 Feb 2024 08:47:38 -0800 (PST)
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 F352AC14F6B3 for <httpbisa-archive-bis2Juki@ietf.org>; Mon, 19 Feb 2024 08:47:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:In-Reply-To:From:References:Cc:To:MIME-Version: Date:Message-ID:Reply-To; bh=pn/jEjN42bRBNWMN+QkiPdEuTxlMQuEtHdOAVsz5kr0=; b= UjF7WzQdC7fN+yIjokYY6Sjd/boccfFfMDNzxGNk5lMQgv/zEjXnSlKxSWJ9uWnxDvNTJ+UjEPCBW yzEK7O3R3dRiDMyAV/bm8YtbWLQsmPGsuBngclYK/434Gcvi6AfyFZ85c5tuIevjlAAm3yC5jXJhd 7QSvplXFCGRiJIHAOFij4fWhjXati+UZlcoOy1X+ZBGYYqdhM11i+wgrC8qa0g8X//t7lOypPAOKM 4SQx4IlRdln3wBXO2ozs8x0eQGBBio9vdtrTnpi+WvuKySQolf97Wr/qBO9nNQ7ou/c6muDVoV/M9 WnzbV8wFi8DkOy0yO7yx+5A19f8ju8f/Iw==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rc6m8-00HUKw-As for ietf-http-wg-dist@listhub.w3.org; Mon, 19 Feb 2024 16:45:52 +0000
Resent-Date: Mon, 19 Feb 2024 16:45:52 +0000
Resent-Message-Id: <E1rc6m8-00HUKw-As@lyra.w3.org>
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 <rousskov@measurement-factory.com>) id 1rc6m6-00HUJv-IQ for ietf-http-wg@listhub.w3.org; Mon, 19 Feb 2024 16:45:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version: Date:Message-ID:Reply-To; bh=pn/jEjN42bRBNWMN+QkiPdEuTxlMQuEtHdOAVsz5kr0=; t=1708361150; x=1709225150; b=Arph2z3WCmiGFviyFXL7FL5lAA6AA7fqxdwDixYuS56PuM/ 04zzTRsoYgS5YrUgulqcthzkDhrxjLcHjI90HmiswMAv9fZJAM9ak4stCgwNQwl7xyn7dC6iyA+gF ZfewoCJCp0JqI2FbM0kCokMoVsSBcBfgda1yZxLd8LlF4h9oZufBI/32H1tRZJeYCRetff2LYytnM M6kZ58cmOBGlqL3tpqWoLhAA6pK9XHnpDuF/JAKI9gXhvnRmj2AYi2Ww8g8woSkMIgCdo4CMCWYu+ fkwEv1LulkPCiU78n4/yOqRMJUD62ZYNBoDmdi/BshwBDpatYDuHoKIWkhkHHuDA==;
Received-SPF: pass (pan.w3.org: domain of measurement-factory.com designates 104.237.131.42 as permitted sender) client-ip=104.237.131.42; envelope-from=rousskov@measurement-factory.com; helo=mail.measurement-factory.com;
Received: from measurement-factory.com ([104.237.131.42] helo=mail.measurement-factory.com) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <rousskov@measurement-factory.com>) id 1rc6m5-001m55-26 for ietf-http-wg@w3.org; Mon, 19 Feb 2024 16:45:50 +0000
Received: from [192.168.1.74] (unknown [199.185.175.160]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id A44AFE03D; Mon, 19 Feb 2024 16:45:45 +0000 (UTC)
Message-ID: <add2c71b-5a2f-49bd-a7af-557bd3f522f2@measurement-factory.com>
Date: Mon, 19 Feb 2024 11:45:44 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Mark Nottingham <mnot@mnot.net>
References: <89474d6f-4a47-4368-ad5d-e671499ba05f@measurement-factory.com> <323B7C7C-1BEA-4ED7-B102-97650DB8176C@mnot.net>
From: Alex Rousskov <rousskov@measurement-factory.com>
In-Reply-To: <323B7C7C-1BEA-4ED7-B102-97650DB8176C@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, RCVD_IN_DNSWL_HI=-5, 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 1rc6m5-001m55-26 26add12f03e499a77990a3062c2052d0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Collapsed requests and response freshness checks
Archived-At: <https://www.w3.org/mid/add2c71b-5a2f-49bd-a7af-557bd3f522f2@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51802
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/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2024-02-17 17:38, Mark Nottingham wrote:

> I'd answer 'yes' and 'yes' -- unless there's something in the
> response that makes it ineligible for use with a particular request,
> there's no reason to think that the server will respond any
> differently to a subsequent retry of that request. In this view, the
> response is treated as if it's a response to each individual request,
> rather than being something that has already been stored by a cache.

Glad I asked! AFAICT, with the above interpretation, the origin server 
cannot insist on seeing every request while also making its response 
cacheable.


> I agree that it's not clear in the spec

I am looking forward to the corresponding spec improvements, both in 
terms of defining which requests may be collapsed and clarifying which 
"MUST NOT reuse" rules from RFC 9111 Section 4 do not apply to collapsed 
requests.


> One of the things we factored out of 2616 was the concept of
> 'first-hand' - it might be useful again here.

It might -- RFC 2616 Section 13.2.1. explicitly excluded "first-hand 
responses" from "expiration mechanism".

RFC 2616 first-hand responses implicitly included responses in collapsed 
transactions AFAICT: "A response is also first-hand if its validity has 
just been checked directly with the origin server", although I do not 
know whether that alleged inclusion was an accident -- I do not know 
whether anybody thought that such a first-hand response may be to a 
_different_ request.

     first-hand
     A response is first-hand if it comes directly and without
     unnecessary delay from the origin server, perhaps via one or more
     proxies. A response is also first-hand if its validity has just
     been checked directly with the origin server.

Arguably, collapsed requests may experience an "unnecessary delay" 
(because they become dependent on another request that may be delayed 
for reasons specific to _that_ request). We can use the "also" clause to 
classify responses in collapsed transactions as first-hand.


> I already have an issue[1] open to probe the edges of collapsed
> forwarding for cache-tests.fyi; I'll try to explore these aspects too
> when I get to it.

Meanwhile, I will be working on adjusting Squid to skip freshness checks 
(and, hence, revalidation) for responses in collapsed transactions.


Thank you,

Alex.


> 1. https://github.com/http-tests/cache-tests/issues/129
> 
> 
> 
>> On 18 Feb 2024, at 09:02, Alex Rousskov <rousskov@measurement-factory.com> wrote:
>>
>> Hello,
>>
>>     RFC 9111 Section 4[1] says "cache can use a response that is stored or storable to satisfy multiple requests, provided that it is allowed to reuse that response for the requests in question". I am trying to understand which rules allow or prohibit that reuse. My guess is that _all_ "MUST not reuse a stored response unless..." rules in that Section apply, but since the response to the collapsed request is not necessarily a "stored response" (i.e. it could be "storable"), I want to double check.
>>
>> For example, can a cache reuse a stale-on-arrival response to satisfy a collapsed request (without doing revalidation)? Let's assume the response in question is not "allowed to be served stale". Informally, the response in question is nearly as fresh as they get because it is being received to satisfy a _concurrent_ request (that our request has collapsed on). However, formal freshness rules may still require treating this response as stale (e.g., max-age=0), either in general (i.e. for any request) or with respect to our collapsed request.
>>
>> Similarly, can a cache reuse a stale-on-arrival response with a must-revalidate directive to satisfy a collapsed request (without doing revalidation)? Here, the wiggle room for reuse appears to be even smaller because a cache "MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin".
>>
>> I suspect the answers are "no" and "no", and, more generally speaking, there are just no reuse exceptions for collapsed requests compared to regular cache hits -- a cache has to treat the incoming response as if it was a previously stored cache hit, even though the response may still be coming into the cache (as the result of the original request that our request has collapsed on). In other words, all Section 4 reuse rules[1] apply. I would appreciate a confirmation.
>>
>>
>> Thank you,
>>
>> Alex.
>>
>> [1]: https://www.rfc-editor.org/rfc/rfc9111.html#name-constructing-responses-from
>>
> 
> --
> Mark Nottingham   https://www.mnot.net/