Re: Server Push and Caching

"Roy T. Fielding" <fielding@gbiv.com> Sun, 11 September 2016 13:17 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 C9D8712B0F0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 11 Sep 2016 06:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.529
X-Spam-Level:
X-Spam-Status: No, score=-8.529 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.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
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 a5gyJX6ThqfA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 11 Sep 2016 06:17:53 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3A912B0A3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 11 Sep 2016 06:17:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bj4Z1-0006Sz-7F for ietf-http-wg-dist@listhub.w3.org; Sun, 11 Sep 2016 13:12:51 +0000
Resent-Date: Sun, 11 Sep 2016 13:12:51 +0000
Resent-Message-Id: <E1bj4Z1-0006Sz-7F@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1bj4Yp-0006SE-Qx for ietf-http-wg@listhub.w3.org; Sun, 11 Sep 2016 13:12:39 +0000
Received: from sub5.mail.dreamhost.com ([208.113.200.129] helo=homiemail-a122.g.dreamhost.com) by lisa.w3.org with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <fielding@gbiv.com>) id 1bj4Yo-0000YY-1y for ietf-http-wg@w3.org; Sun, 11 Sep 2016 13:12:39 +0000
Received: from homiemail-a122.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a122.g.dreamhost.com (Postfix) with ESMTP id 026DD60001115; Sun, 11 Sep 2016 06:12:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=0Xd2v2UuWnSQGGhwi5N/p2K3Fdo=; b=vzaqUgn0cMr367Qyo1jfdPmJRok6 3P/P2S34FCJNC2tQfzR7wdAQMPS35uEEThMYLH7RGPKO6pH9LhY+XVdZUNSfShSW m4MSoTHKII+WOkHryPYPC9VeVqhjjen1N3W9k0uU2nced2aBb0wkjRvJgGDDU7r6 nl2k4gQqjaSlfvE=
Received: from [192.168.1.3] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a122.g.dreamhost.com (Postfix) with ESMTPSA id D988D60001101; Sun, 11 Sep 2016 06:12:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <E1890F7D-5769-4315-9467-33BCC602D628@mnot.net>
Date: Sun, 11 Sep 2016 06:12:14 -0700
Cc: Tom Bergan <tombergan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <130AA43A-9C83-41DE-9D84-D82F74EF81EC@gbiv.com>
References: <3904FEC0-4362-47A0-886A-B97FB97E2515@mnot.net> <CA+3+x5F+KVMvfDu=+H0-ScqiYbGL5RPcF9wfZ5992Q=xcp1k8A@mail.gmail.com> <B42CD662-950E-4D91-AE73-29AFEE584E49@gbiv.com> <8D8D93DF-19A7-4C1F-AC6E-F8FD9213A2D8@mnot.net> <57026FC8-C02C-46A1-97B1-B166CEB4D7C3@gbiv.com> <E1890F7D-5769-4315-9467-33BCC602D628@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com; helo=homiemail-a122.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: AWL=1.182, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bj4Yo-0000YY-1y 43421f2719938fca982d8277a186af93
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Server Push and Caching
Archived-At: <http://www.w3.org/mid/130AA43A-9C83-41DE-9D84-D82F74EF81EC@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32390
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Sep 7, 2016, at 5:06 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> On 8 Sep 2016, at 3:22 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>>>>> Note that HTTP does not put constraints on _how_ the application uses that response after it comes through the API or the cache; it might use it multiple times (e.g., an image might occur more than once on a page, or more than one downstream client might have made the request). It's just that this reuse isn't in the context of a HTTP cache's operation.
>>> 
>>> You're correct that an HTTP *client* isn't required to revalidate a response, but a cache is.
>> 
>> A cache isn't required to revalidate.  Only a client revalidates, and only
>> when it wants to do so.  A cache never makes requests.  A cache is only required
>> to mark the response as stale.
> 
> From previous discussions, I know that's your view, and I think it's internally consistent. I'm less convinced that view is shared by implementations, or even the specs.
> 
> RFC 7234, Section 4: "A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use."

Yes, that spec plays loose with the terminology.  Clients make requests.
In some cases, a cache contains a client. In other cases, a cache just
tells the calling client what it currently contains, and is updated as a
side-effect of whatever responses are received.

BTW, I haven't seen any evidence of that requirement enforced, at least for caches
that have an interval timer instead of a wall clock.  They just count the age.

> Section 4.2.4: "A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2)."

That's inconsistent -- it should be "MUST NOT use a stale response".  The reason
the spec has this requirement is because a cache MAY use a stale response
if it is not prohibited by those explicitly specific directives.

> Section 4.3.2: "When a cache decides to revalidate its own stored responses for a request..."

Should be "When a cache revalidates a stored response ..."

> Section 5.2.2.1: "The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server."

That's fine.

> Section 5.5.2:" A cache SHOULD generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach the server."

Which wrongly assumes that a cache is a server (as does 4.2.4).

> 2616 contains much the same language.

Let's just agree not to go there.

> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/

So, hold for document update?

I don't understand why this is even an argument.  RFC7234 claims that
it is specifying HTTP caching.  We know that caches appear inside all
forms of HTTP components (user agents, proxies, gateways, origin servers)
and in a variety of non-HTTP components (ISPs, captive portals, etc.).
We know that caches are often configured to be less than semantically
transparent.  We cannot seriously define "HTTP cache" to be only those
caches that limit stale reuse to those in section 4.2.4, as if the
components people call a "cache" in real life magically rename themselves
whenever they don't adhere to those requirements.

The reason I stick to my internally consistent views, instead of relying
on the RFC, is because the RFC is not currently capable of describing
how a user agent works with its own cache.  For example, see

  https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

Likewise, semantic transparency isn't sufficient to encompass the configurations
of any performance-enhancing cache, like Squid and Apache TrafficServer.

I think we should just fix section 4.2.4 to not specify things in client/server
terms (rather, a cache adds to or removes from a stored response) and to allow
for cache behavior regarding stale responses to be based on context and
configuration.

Cheers,

....Roy