Re: Server Push and Caching

Patrick McManus <> Fri, 26 May 2017 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42806129BEE for <>; Fri, 26 May 2017 13:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.401
X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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] 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 h03l4W0SQGXs for <>; Fri, 26 May 2017 13:21:05 -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 59C8C129B4C for <>; Fri, 26 May 2017 13:21:04 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1dELgc-0002Bg-SB for; Fri, 26 May 2017 20:18:14 +0000
Resent-Date: Fri, 26 May 2017 20:18:14 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1dELgW-0002Ah-Uh for; Fri, 26 May 2017 20:18:08 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1dELgQ-0005Aa-7U for; Fri, 26 May 2017 20:18:03 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=LbO1Uq9+vlYj2YFY0upW4vPNzII=; b=vNKLgdlleoIOOWEIoo EN8J/CYoN+z93G4+WJpvXeC1tv3P0k9eeeQt1Le7hZAUzBPCOa1IServ+t7wNSKa wlk6fKLCTTSyKe5LWfGvlG2y0cLMMeY4LHK3gpYW+cwarD0xYTwvdNqGCN62Aqnk LF4D5JdrUyEodxsJ4gKJf5LRg=
Received: by with SMTP id filter0811p1mdw1-9893-59288D37-9 2017-05-26 20:16:55.069759171 +0000 UTC
Received: from ( []) by (SG) with ESMTP id 6TAo3vOdSuWbuiMm0u0Vhg for <>; Fri, 26 May 2017 20:16:55.020 +0000 (UTC)
Received: by with SMTP id k74so15760401qke.1 for <>; Fri, 26 May 2017 13:16:55 -0700 (PDT)
X-Gm-Message-State: AODbwcAPYnbdWGF2PlyRr9ctDyC2GcIvhe6q06HrX3DUmCtdjmwdrKzG jvnpREzi2IRN6NR/ObB24GziAOQN3g==
X-Received: by with SMTP id 2mr4353018qkd.166.1495829814687; Fri, 26 May 2017 13:16:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 May 2017 13:16:54 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Fri, 26 May 2017 16:16:54 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: David Witherspoon <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a114c9cc4bfbdf705507304d8"
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh7bhvMq1cmOapl9B3zNPMjiyjFEaieRqLlxBc xAY0QXngJlHkhs2LcTSCLuaN4SPxyrElV0FjLpAMiLgN+72zcyYCL9AGL7bQW/gCezEzFy1SIxFcx/ DOhu1SPv4vNB2ZJu7VoOSW4Y2vzIkabaSuqeDUTbfDV9PG/7J/87V20lBeCAREyEnjO/2XhNwMqWIU Y=
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Scan-Sig: 1dELgQ-0005Aa-7U ff69cf88186ade237b011c8bb2c7f487
Subject: Re: Server Push and Caching
Archived-At: <>
X-Mailing-List: <> archive/latest/33956
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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

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