Re: Server Push and Caching

"Roy T. Fielding" <> Wed, 24 August 2016 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6244212D56F for <>; Wed, 24 Aug 2016 10:22:09 -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 Tr6FHxNbUhTD for <>; Wed, 24 Aug 2016 10:22:08 -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 E921412D162 for <>; Wed, 24 Aug 2016 10:22:07 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcboB-0006ZC-RU for; Wed, 24 Aug 2016 17:17:47 +0000
Resent-Date: Wed, 24 Aug 2016 17:17:47 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcbo4-0006Wb-Id for; Wed, 24 Aug 2016 17:17:40 +0000
Received: from ([] by with esmtps (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1bcbo1-0007nx-Gp for; Wed, 24 Aug 2016 17:17:40 +0000
Received: from (localhost []) by (Postfix) with ESMTP id ACBE86002F2A; Wed, 24 Aug 2016 10:17:14 -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=orfRVswpxbY24lxzVRgZ2gzF1XQ=; b=f 3iOCCQPb4+Gh4G51MYAM8P9LcE1e28KWmc3i+OKKufC8pK6EREAtsPDN0eswyrRc U+CLTxPrKzvn3vUZ6jstCibe/BvfTMp/nfup3oJGmzPdGAlXZD0ZLRUiXfHRRO7A bExGG+iimXfLXkGFL1EErN0GjldyfAd+lk+7Ii+wlo=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 6DD7A6002F28; Wed, 24 Aug 2016 10:17:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4DAAA7C6-EC20-4A8D-B07F-8758810F6304"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Wed, 24 Aug 2016 10:17:13 -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.318, 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: 1bcbo1-0007nx-Gp a9b1cb46e52294a693a49c5d486bb678
Subject: Re: Server Push and Caching
Archived-At: <>
X-Mailing-List: <> archive/latest/32355
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Aug 24, 2016, at 9:28 AM, Tom Bergan < <>> wrote:
> Thanks for starting this thread. I have questions about the following quote from the RFC:
> On Tue, Aug 23, 2016 at 9:50 PM, Mark Nottingham < <>> wrote:
> RFC7540, Section 8.2 says:
> > Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present (RFC7234, Section 5.2.2)) while the stream identified by the promised stream ID is still open.
> This implies that, while that stream is open, the pushed response can be used by the cache, even when it contains any (or all) of the following cache directives:
> * max-age=0
> * no-cache
> * s-maxage=0 (for shared caches)
> The underlying principle here is that while the response stream is still open, it's semantically equivalent to a "normal" response to a just-issued request; it would be senseless to require it to be immediately revalidated before handing it to the application for use.
> The cache can also store the response, but once the stream is closed, if that response is stale -- either because of the presence of one of the directives above, or some combination of `Expires`, `Age`, `Date`, and `Cache-Control`, it will need to be revalidated before use.
> Chrome does not implement this. Some discussion starting here:
> <>
> I can see why the above sentence was added to the RFC -- there needs to be some semantics for pushing immediately-stale responses, and the above sentence seems like reasonable semantics at first glance. However, I'm concerned that these semantics are not implementable in practice. On the client side, the user agent will typically store pushed responses in a side cache until they are matched with an actual request. On the server side, the server will send END_STREAM with the last DATA frame in the pushed response. This creates a race where the client may see END_STREAM before it's done enough processing to realize that it needs the pushed response. For example, consider cases where the server tries to push an "inlined" resource, but happens to push the inlined resource before the referencing HTML tag.
> A server might try to avoid this race by holding the stream open, but how long should it keep the stream open? There's no way for the client to signal that a pushed response has matched a request. Further, the client cannot know (in general) if the server is holding a stream open to preserve validity of the no-cache response or because it's slow to send the final DATA frames.
> I'm not sure what the right semantics are. One option is to allow the user agent optional leeway to consider the response validated for a longer period, perhaps using a timeout as Chrome does. Or, perhaps, a browser might consider a pushed response validated for the duration of the parent navigation event. Thoughts?

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).