Re: Server Push and Caching

"Roy T. Fielding" <> Wed, 24 August 2016 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AE6512D660 for <>; Wed, 24 Aug 2016 12:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.568
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9cM0NRPrGbmk for <>; Wed, 24 Aug 2016 12:04:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 112B912D550 for <>; Wed, 24 Aug 2016 12:04:06 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcdNY-0005NN-QY for; Wed, 24 Aug 2016 18:58:24 +0000
Resent-Date: Wed, 24 Aug 2016 18:58:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcdNS-0005Mc-Hg for; Wed, 24 Aug 2016 18:58:18 +0000
Received: from ([] by with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bcdNM-0005pa-8U for; Wed, 24 Aug 2016 18:58:17 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 65C9A60005418; Wed, 24 Aug 2016 11:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc:message-id :references:to;; bh=PkvdMCEbtW1RhmKLNBae15+UIQg=; b=N jpP52IHcJx3/bnWo9wcJlZ1hVBbvWagxxDh1xA8zykqP6xp4cPrZzfVhx6ulZkHU 8Gq0vubSu4iBxcO6TqE5gH19Y8xlpsJ5JcrSiZ9BLY/q6pV9bmpTSGGdufpkX2Lv m2zQ1CaxEw9BiYhS7cobCEWpSZsZlfO53kLeokbTss=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (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" <>
In-Reply-To: <>
Date: Wed, 24 Aug 2016 11:57:46 -0700
Cc: Mark Nottingham <>, HTTP Working Group <>
Message-Id: <>
References: <> <> <> <>
To: Tom Bergan <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: none client-ip=;;
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: 1bcdNM-0005pa-8U 8a2130fe43d3f157057b47dd3bcf5033
Subject: Re: Server Push and Caching
Archived-At: <>
X-Mailing-List: <> archive/latest/32361
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Aug 24, 2016, at 11:23 AM, Tom Bergan <> wrote:
> On Wed, Aug 24, 2016 at 10:17 AM, Roy T. Fielding < <>> 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.