Re: Server Push and Caching

David Witherspoon <> Fri, 26 May 2017 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 240761204DA for <>; Fri, 26 May 2017 14:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.5
X-Spam-Status: No, score=-6.5 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kySRkWXL0fuv for <>; Fri, 26 May 2017 14:54:52 -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 8F4E01243F6 for <>; Fri, 26 May 2017 14:54:52 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1dEN8y-0007h0-SM for; Fri, 26 May 2017 21:51:36 +0000
Resent-Date: Fri, 26 May 2017 21:51:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1dEN8t-0007fl-VC for; Fri, 26 May 2017 21:51:31 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1dEN8m-0001Bt-8Z for; Fri, 26 May 2017 21:51:26 +0000
Received: by with SMTP id p85so11044623vkd.3 for <>; Fri, 26 May 2017 14:51:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kP4C0C0S2xoZ7B7sSBsnKATs/+pscxu4sz5pKhZ/Wvk=; b=RKKL+i1X0QYgs0Jzxw2bOWjFiVGK0ZFBz76uiq34qgaNaJs2D9cM1khfVwCbwEfZFT 0/iRQtZZfaoJSvFvm+gKBX/mgZaqMzTJVniZKH1m70kQI5TP86sbvfGD2JqfZupE+htk ZUQtQnbpp/9kzrGE6eO5YDVs3y5q8tft5opBl5x1HXWeLgoTsbEZbXpDJwAiiMF7Inoy ejQPMRkQ33F7VbMlUlMvF901Cj6HEPYsy+iQwoHVLGbduTOCHetP+hXYrhH3Idpvkpl1 tqytVGoHp4zH3WFeeV4gFYydCp6TrLP7fOxUOC+99wPWURTv0sz2YrIZ3BXC9B6A6fu0 gMXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kP4C0C0S2xoZ7B7sSBsnKATs/+pscxu4sz5pKhZ/Wvk=; b=cj2uGNQk8zRGA0tP781TbDXQfGq5WfeTamxsKeCh8tWtqv28JZZ+fgNr5dhPmVFVtW Vedj5Pxhn0bxxHXw3gOMA/dCXFfXCaN9s2xS1JI0Lu4IJLxkFKJnmhHRX9+7JYtEy+V2 yhke4ZYBXcVdDGCHRe+V+jTgN27QHh7guPUpZ8w1PunkDblBE5imvlZbA0OQ+xzst2ao 1uwRUTceZPnOzMImPnJ8cQ1zDZzVqyP9p60jrMGji4MZ5Wo4Vl+oVEWAbLW4ZpfUWWLQ OyK0o7rSfqmzmJwm+uo+Kf+8GIINiaI4nVPF+SQnzb4dr3uAGcMCbUBHTE1hrrrt4kne Z1+A==
X-Gm-Message-State: AODbwcDqvLWIyvm7JLXgdsEQPhxiKvVbdAJv6prr6QFjZF5b3pSLQguH drg2h+0xi4pgULvEdIWvosE9BDhflSSG8Zk=
X-Received: by with SMTP id 193mr1334597vkh.132.1495835457507; Fri, 26 May 2017 14:50:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 May 2017 14:50:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: David Witherspoon <>
Date: Fri, 26 May 2017 14:50:57 -0700
Message-ID: <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a1143d320165735055074554e"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Scan-Sig: 1dEN8m-0001Bt-8Z 5045131ac30fe39426f5c7bcef9918cf
Subject: Re: Server Push and Caching
Archived-At: <>
X-Mailing-List: <> archive/latest/33957
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Yes, thanks for the clarification.  I agree invalidation is too strong of
wording.  Rather a request with cache-control: no-cache directive allows
for updating or adding entries to the cache.

> it certainly doesn't MUST or even SHOULD it.

I believe I might still disagree but let me clarify the scenario:

1. client issues request 1, and gets a cache-able response 1.
2. The client then issues the same request (request 2) but with the
no-cache cache request directive and gets a cache-able response 2 from the
origin server.
3.  The client issues request 3 that matches both previous requests and
assume both responses are valid.  rfc7234#section-4.4 states that "When
more than one suitable response is stored, a cache MUST use the most recent
response".  So response 2 would presumably be served from cache to answer
request 3  (OR It can also forward the request with "Cache-Control:
max-age=0" or "Cache-Control: no-cache" to disambiguate which response to

If we now assume that request 2 is server-initiated via a push promise, and
that the push promise is not cancelled, and the client "is just replaying"
it onto the cache then I would assume Step 3 MUST operate in the same way.

> I do agree that a cached-response that you wouldn't use to satisfy the
pushed request is not a good rationale for canceling the pushed stream

Agreed, this arose because Chrome has a PR that implements an optimization
on their implementation of just replaying it onto the cache.  That
optimization "Cancel[s] unnecessary push streams when it's discovered
they're in cache".  I believe the semantics of a no-cache request header is
well defined such that it can't already be discovered in cache.  Sure it
can cancel the Push Promise for any reason, but in this case, it is
ignoring the semantics that the no-cache request directive syntax defines.

Note, if response 2 has a longer validation lifetime then response 1, then
I believe it is behaviorally equivalent to invalidating response 1.

On Fri, May 26, 2017 at 1:16 PM, Patrick McManus <>

> On Wed, May 24, 2017 at 1:27 PM, David Witherspoon <
>> wrote:
>> > The only native HTTP mechanism for cache invalidation is described in
>> RFC7234, Section 4.4:
>> [
>> RFC7234 Section defines one, (request cache-directive, no-cache):
>> The “no-cache” request directive indicates that a cache MUST NOT use
>> a stored response to satisfy the request without successful
>> validation on the origin server.
> istm that you are confusing invalidation with use. doesn't say
> anything about invalidating the cache - bypassing when satisfying that
> request is fine and even sensible if you expect multiple variants. Sec 4.4.
> does talk about invalidation in the face of responses to unsafe methods but
> a] 7540 does not allow pushing unsafe methods, and b] 4.4. is clear that
> this only applies to caches that it "travels through" and its not clear
> that 7540 push operates directly on a cache even though it has cache
> semantics.
> its not clear exactly how pushes should be applied by clients.. they are
> making small movements towards "just replaying them" onto the cache
> directly, but its obvious that can't be the whole story.. e.g. a response
> containing cache-control: no-store is explicitly allowed for use by 8.2 and
> that wouldn't work if promised streams were just directly use to populate a
> cache.
>> It would be semantically incorrect to cancel a server-initiated request
>> with a no-cache request directive for the sole reason that it is already
>> has a cached response.
> I don't know that I would go as far as "semantically incorrect" because I
> don't think you have the semantics you're looking for :).. but I do agree
> that a cached-response that you wouldn't use to satisfy the pushed request
> is not a good rationale for canceling the pushed stream. But as far as
> correctness goes, you don't need a good reason to correctly cancel any push.
>> In fact, the premise that a server-initiated request with a no-cache
>> request directive can already have a cached response violates semantic
>> equivalency. Any request, client or server initiated, with a no-cache
>> request directive can not by RFC have a validated response in the cache.
> I would agree with that. but I think you might also be implying that the
> cache needs to invalidate any previously stored entry for the same URL..
> and I don't agree with that :) (though it could.)
>> Assuming the Push Promise goes through (client still may cancel the Push
>> Promise for any reason), this clearly allows for overwriting an existing
>> cached response, specifically replacing a cache entry.
> I agree it allows that. it certainly doesn't MUST or even SHOULD it. It
> might be reasonable.