dont-revalidate Cache-Control header
Ben Maurer <ben.maurer@gmail.com> Thu, 09 July 2015 22:29 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3324D1A1B44 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jul 2015 15:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_kg5iLqFhgY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 Jul 2015 15:29:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB301A1B51 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 Jul 2015 15:29:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZDKGQ-0004CU-7V for ietf-http-wg-dist@listhub.w3.org; Thu, 09 Jul 2015 22:25:54 +0000
Resent-Date: Thu, 09 Jul 2015 22:25:54 +0000
Resent-Message-Id: <E1ZDKGQ-0004CU-7V@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ben.maurer@gmail.com>) id 1ZDKGL-0004Be-U5 for ietf-http-wg@listhub.w3.org; Thu, 09 Jul 2015 22:25:49 +0000
Received: from mail-lb0-f171.google.com ([209.85.217.171]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <ben.maurer@gmail.com>) id 1ZDKGK-00069A-4a for ietf-http-wg@w3.org; Thu, 09 Jul 2015 22:25:49 +0000
Received: by lbzd8 with SMTP id d8so37483105lbz.0 for <ietf-http-wg@w3.org>; Thu, 09 Jul 2015 15:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Hjp4cWvCq4Um6WHP91JYABvXYTrxTfZSfxPXEPdsTG4=; b=hGTdisCexAnJAik5/y7W8QKwexCZEGaxzvRrXREbno7COpntkakm8GOoaqo5YPQr8N h6mEBWrokcdnGaPLvPCEuqZHANS1Dwl1hyEE5ZzzSXN0KpEc+G3N6OWy/ZFdW4CMuOjF kLMYnUQ12NqTC0FzwVHa2JhrxFsUxlWC5V+e7jJQRHpVpqIAZ45WJWKyg1Fkxeg5wH+v wYeL2aGU9pBZtvhNKTlONlVow0KiIw2r8QWpJeuwByTUB1JGybqlYxvfZkaBZF3ITw+B g4MDcaeztOc3U9gRKjhpaw1iiK+qbke1maGBCDwtd9cNCtjfRK/5XuXD7seWIJyDt7Tq L4+A==
MIME-Version: 1.0
X-Received: by 10.152.206.75 with SMTP id lm11mr16548840lac.41.1436480721023; Thu, 09 Jul 2015 15:25:21 -0700 (PDT)
Received: by 10.25.163.147 with HTTP; Thu, 9 Jul 2015 15:25:20 -0700 (PDT)
Date: Thu, 09 Jul 2015 15:25:20 -0700
Message-ID: <CABgOVaLHBb4zcgvO4NUUmAzUjNkocBGYY3atFA9iuYyoLaLQsA@mail.gmail.com>
From: Ben Maurer <ben.maurer@gmail.com>
To: ietf-http-wg@w3.org, Ilya Grigorik <igrigorik@google.com>
Content-Type: multipart/alternative; boundary="001a1133bdc61a77b3051a78bb8b"
Received-SPF: pass client-ip=209.85.217.171; envelope-from=ben.maurer@gmail.com; helo=mail-lb0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: AWL=-0.911, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ZDKGK-00069A-4a 07fe7badb0281e6d25c437236006b715
X-Original-To: ietf-http-wg@w3.org
Subject: dont-revalidate Cache-Control header
Archived-At: <http://www.w3.org/mid/CABgOVaLHBb4zcgvO4NUUmAzUjNkocBGYY3atFA9iuYyoLaLQsA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29912
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
It is considered a best practice for websites to use "long caching" for serving images, javascript and CSS. In long cacing if a website has a resource X.js which might change from time to time, rather than referencing X.js and giving the endpoint a short expiration date, they reference X-v1.js with a nearly infinite expiration date. When X.js changes, the website uploads X-v2.js and changes any references to use the new version. This has the benefit that the browser never needs to revalidate resources and that it sees changes instantly. [1] At Facebook, we use this method to serve our static resources. However we've noticed that despite our nearly infinite expiration dates we see 10-20% of requests (depending on browser) for static resource being conditional revalidation. We believe this happens because UAs perform revalidation of requests if a user refreshes the page. Our statistics show that about 2% of navigations to FB are reloads -- however these requests cause a disproportionate amount of traffic to our static resources because they are never served by the user's cache. A user who refreshes their Facebook page isn't looking for new versions of our Javascript. Really they want updated content from our site. However UAs refresh all subresoruces of a page when the user refreshes a web page. This is designed to serve cases such as a weather site that says <img src="/weather.php?zip=94025">. If that site had a 10 minute expiration on the image, the user might be able to refresh the page and get more up to date weather. 10-20% additional requests is a huge impact for a site's performance. When a user presses refresh, they want to quickly see the latest updates on the site they are on. Revalidating all resources on the site is a substantial drain. In discussing this with Ilya Grigorik from the Chrome team, one suggestion that came up was an explicit cache control option to tell UAs not to revalidate. The proposed header would be Cache-Control: dont-revalidate This header would tell a UA that the resource in question is unquestionably valid until it's expiration time. A UA MUST NOT send a conditional request for a resource with a dont-revalidate header prior to the resource's expiration. In most cases the UA SHOULD simply treat the resource as valid. If the UA is not willing to treat the resource as valid, it should send a full request with no revalidation. The UA MAY do this in cases where the user has explicitly requested to use a clean cache -- for example a refresh via ctrl+shift+r, or using developer tooling. Such functionality SHOULD be targeted at advanced users rather than the average user. Without an additional header, web sites are unable to control UA's behavior when the user uses the refresh button. UA's are rightfully hesitant in any solution that alters the long standing semantics of the refresh button (for example, not refreshing subresources). [1] https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#invalidating-and-updating-cached-responses
- dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Amos Jeffries
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Zhong Yu
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Mark Nottingham
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Adam Rice
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Ilya Grigorik
- Re: dont-revalidate Cache-Control header Bryan McQuade
- Re: dont-revalidate Cache-Control header Amos Jeffries
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Mark Nottingham
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Ilya Grigorik
- Re: dont-revalidate Cache-Control header Roy T. Fielding
- Re: dont-revalidate Cache-Control header Ilya Grigorik
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Martin Thomson
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Amos Jeffries
- Re: dont-revalidate Cache-Control header Mark Nottingham
- Re: dont-revalidate Cache-Control header Mark Nottingham
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Mark Nottingham
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Amos Jeffries
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Martin Thomson
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Martin Thomson
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Martin Thomson
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Roy T. Fielding
- Re: dont-revalidate Cache-Control header Ben Maurer
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Amos Jeffries
- Re: dont-revalidate Cache-Control header Guille -bisho-
- Re: dont-revalidate Cache-Control header Amos Jeffries