Re: Server Push and Caching

"Roy T. Fielding" <fielding@gbiv.com> Wed, 24 August 2016 19:04 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 5AE6512D660 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 12:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.568
X-Spam-Level:
X-Spam-Status: No, score=-7.568 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 9cM0NRPrGbmk for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 12:04:06 -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 112B912D550 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Aug 2016 12:04:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bcdNY-0005NN-QY for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Aug 2016 18:58:24 +0000
Resent-Date: Wed, 24 Aug 2016 18:58:24 +0000
Resent-Message-Id: <E1bcdNY-0005NN-QY@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 1bcdNS-0005Mc-Hg for ietf-http-wg@listhub.w3.org; Wed, 24 Aug 2016 18:58:18 +0000
Received: from sub5.mail.dreamhost.com ([208.113.200.129] helo=homiemail-a126.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 1bcdNM-0005pa-8U for ietf-http-wg@w3.org; Wed, 24 Aug 2016 18:58:17 +0000
Received: from homiemail-a126.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a126.g.dreamhost.com (Postfix) with ESMTP id 65C9A60005418; Wed, 24 Aug 2016 11:57:47 -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:message-id :references:to; s=gbiv.com; bh=PkvdMCEbtW1RhmKLNBae15+UIQg=; b=N jpP52IHcJx3/bnWo9wcJlZ1hVBbvWagxxDh1xA8zykqP6xp4cPrZzfVhx6ulZkHU 8Gq0vubSu4iBxcO6TqE5gH19Y8xlpsJ5JcrSiZ9BLY/q6pV9bmpTSGGdufpkX2Lv m2zQ1CaxEw9BiYhS7cobCEWpSZsZlfO53kLeokbTss=
Received: from [192.168.1.7] (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-a126.g.dreamhost.com (Postfix) with ESMTPSA id 446A760005415; Wed, 24 Aug 2016 11:57:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2749ADED-19C8-4936-9145-7BB13910AF03"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CA+3+x5H9sQ3wnErAT2kvB9+G1Mxnzm7jf0DjO2=AZAADyEJaAQ@mail.gmail.com>
Date: Wed, 24 Aug 2016 11:57:46 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <9E239832-E536-4012-9D0E-C51070017F7D@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> <CA+3+x5H9sQ3wnErAT2kvB9+G1Mxnzm7jf0DjO2=AZAADyEJaAQ@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=208.113.200.129; envelope-from=fielding@gbiv.com; helo=homiemail-a126.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: AWL=-0.315, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bcdNM-0005pa-8U 8a2130fe43d3f157057b47dd3bcf5033
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Server Push and Caching
Archived-At: <http://www.w3.org/mid/9E239832-E536-4012-9D0E-C51070017F7D@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32361
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 Aug 24, 2016, at 11:23 AM, Tom Bergan <tombergan@chromium.org> wrote:
> 
> On Wed, Aug 24, 2016 at 10:17 AM, Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>> wrote:
> FWIW, the mistake above is in saying "response is stale … it will need to be revalidated".
> 
> An HTTP client is not required to revalidate a stale response.  It only needs to do so when
> ensuring semantic transparency, which is something that user agents frequently don't do
> within the scope of a single session (instead, they make requests based on configuration
> or on the state of their own request processing).
> 
> Out of curiosity, can you walk through how you arrived at that interpretation for this specific case? Are you essentially suggesting that the "push store" (or "side cache") should be treated more like a history list (RFC 7234, Section 6) rather than a true HTTP cache?

I mean that the hypermedia workspace (set of open windows, tabs, in-process memory, side cache, history, or whatever else you want to include in however you might want to implement a browser, which is completely unconstrained by HTTP) is not a cache at all -- it is part of the current rendering process of the browser. How you program that process to behave is entirely defined by you, not HTTP. Some people have written user agents that browse off-line CDROM content mapped into cache form as if it were a live website with stale backing content, regardless of how stale that content might be, because they were specifically designed for that purpose. Some users configure their browser in "never check" mode, because they prefer stale over "costs money".

It is not the responsibility of HTTP to define the process by which pushed responses are used; HTTP only defines how they are sent and what they mean upon receipt.

For the same reason, HTTP cache requirements provide rules for adhering to semantic transparency when it is desired. They do not require that every message store be a semantically transparent HTTP cache.

....Roy