Re: Server Push and Caching

Tom Bergan <> Wed, 24 August 2016 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79A0912D544 for <>; Wed, 24 Aug 2016 09:33:11 -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 ClhWzK7oHj19 for <>; Wed, 24 Aug 2016 09:33:09 -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 C281412D548 for <>; Wed, 24 Aug 2016 09:33:08 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcb2p-0002s0-Dd for; Wed, 24 Aug 2016 16:28:51 +0000
Resent-Date: Wed, 24 Aug 2016 16:28:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcb2e-0002qy-8n for; Wed, 24 Aug 2016 16:28:40 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcb2c-00068P-7m for; Wed, 24 Aug 2016 16:28:39 +0000
Received: by with SMTP id f6so43194826ith.0 for <>; Wed, 24 Aug 2016 09:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rWm8KK67W9mgXisvrzbap/Fq/tGXgUegUbehXiGwj8I=; b=K6JD3AOaPnMKesvVlK6OwX1RxrFjBZAw9G42nBdxmLn4JMGKLbCtUhTOzktmF9Q8+N oK9A12fCKrocbC3+9rlUSlIReYjuSCEYElodCrZzDQZ5+zPpK+yGqNyAH2/0Ugups/+T tYltTI0h1yURYUGwEIXT4n5dMhL+5Mnlq7ezY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rWm8KK67W9mgXisvrzbap/Fq/tGXgUegUbehXiGwj8I=; b=AiYRG/i9yOcxtJ70642KdSga+pc3aUSNmZsddR6AdMzrdum2htSvqtKWIbPwRmpTLI vIMWyquzkEhmAuwYpm0XzitfQqLeRNaojcca9SXDmj9i76JDkvuSk94gEq9lp6g0sq+9 aCUhR22xFtXUe/uSe4fMRS+gVNXxvWxk/WDT5mFIaea0S1YrU2avi+ghqBIX8dgnX2N7 HWON8379wGLGXBoTe+KlrzHtWYeg0bCqTnSYPGT2uRlHPGiKnPr14h/HVhFRvQLSRViP Jsdi+Z8047h/OZaRlAgjSmqH5wQGcemIfCOTPUdfmUXaE8sHOcpt8D++8+g2Sgs7yCGA 4/wQ==
X-Gm-Message-State: AE9vXwP6UAnZHeefaEXBAhGu/vlO224EI1pkinm/GGNspDJIirl9qvpynjjBTzK0LZtonNr1
X-Received: by with SMTP id d5mr5954339iof.62.1472056091735; Wed, 24 Aug 2016 09:28:11 -0700 (PDT)
Received: from ( []) by with ESMTPSA id b133sm8864536iti.21.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Aug 2016 09:28:11 -0700 (PDT)
Received: by with SMTP id f6so43193377ith.0 for <>; Wed, 24 Aug 2016 09:28:10 -0700 (PDT)
X-Received: by with SMTP id e186mr33974594itb.56.1472056090467; Wed, 24 Aug 2016 09:28:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Aug 2016 09:28:10 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Tom Bergan <>
Date: Wed, 24 Aug 2016 09:28:10 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a1143b92e5d030d053ad3c475"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.760, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bcb2c-00068P-7m 8e7c47e26feaf3ff9161df4f9314dc43
Subject: Re: Server Push and Caching
Archived-At: <>
X-Mailing-List: <> archive/latest/32352
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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?