Re: dont-revalidate Cache-Control header

Amos Jeffries <squid3@treenet.co.nz> Fri, 17 July 2015 18:01 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 6BBDC1ACE49 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jul 2015 11:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FgChP5BORqaH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jul 2015 11:01:55 -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 B9FC51ACE42 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Jul 2015 11:01:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZG9tr-0008N3-7k for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Jul 2015 17:58:19 +0000
Resent-Date: Fri, 17 Jul 2015 17:58:19 +0000
Resent-Message-Id: <E1ZG9tr-0008N3-7k@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1ZG9tn-0008MM-W1 for ietf-http-wg@listhub.w3.org; Fri, 17 Jul 2015 17:58:16 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <squid3@treenet.co.nz>) id 1ZG9tm-0003Rj-C9 for ietf-http-wg@w3.org; Fri, 17 Jul 2015 17:58:15 +0000
Received: from [192.168.20.251] (unknown [121.98.42.176]) by treenet.co.nz (Postfix) with ESMTP id 06462E6D9D for <ietf-http-wg@w3.org>; Sat, 18 Jul 2015 05:57:40 +1200 (NZST)
Message-ID: <55A941F6.90608@treenet.co.nz>
Date: Sat, 18 Jul 2015 05:57:10 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <CABgOVaLHBb4zcgvO4NUUmAzUjNkocBGYY3atFA9iuYyoLaLQsA@mail.gmail.com> <16407353-5C34-42E8-81A6-E0027EC3A0D0@mnot.net> <CABgOVa+C48yYp-ZkawY+Ho6pXONa_UfB0MVt_2+d0ejyESu2Pw@mail.gmail.com> <54973543-2406-4188-8DCD-AE3C85ACB76A@mnot.net> <CABgOVa+CrJ0qBGN-nBYZ2qpJo8X+wkYY-zYAqM6MjTom1QT+Bw@mail.gmail.com> <55A7A4F9.1010500@treenet.co.nz> <CABgOVaLnpnmd7JvY6O=tXXboVuvCCn-p1KLzu8wKVkg-yon79w@mail.gmail.com> <CAMSE37vmBJYkiC+c5+aMqWUvLtY4zOHDbhEJkm=K+=KbTyOO2A@mail.gmail.com> <CABkgnnXNAZdXUx_htq2owyP2CtyM-ERzZdbxM8WGWLrCeNQOaQ@mail.gmail.com> <CAMSE37v6qXzNquAqGPaHgVJYwfGeC+uE1hurc7g4wvoL1nvgkA@mail.gmail.com> <CABkgnnX3OMJ2=5AQcYHB9XeN0TEo0OTrcRmrpBujrqCNwnjOag@mail.gmail.com> <CAMSE37uwbLokWApCUMtj5G9zW4p5RzY63XOx-+VeiRdouw3-SA@mail.gmail.com> <CABkgnnWG9mSg=pCT91tVfEEs1TCxHVnNWRopsPTr+eC4K4Vewg@mail.gmail.com> <CABgOVaKWKjVcbKpMj-KtWzO1O+VVSDKSH80t3pisoPAM8mt+7A@mail.gmail.com> <CAMSE37sy1bVxCRKJ46CPFqOiR+BO1hNqQaACKCDFPiKvcSFAxg@mail.gmail.com>
In-Reply-To: <CAMSE37sy1bVxCRKJ46CPFqOiR+BO1hNqQaACKCDFPiKvcSFAxg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-0.095, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1ZG9tm-0003Rj-C9 dc3e44c78fbc057ef40e7f7554b690a9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: dont-revalidate Cache-Control header
Archived-At: <http://www.w3.org/mid/55A941F6.90608@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29985
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>

On 18/07/2015 5:26 a.m., Guille -bisho- wrote:
> On Fri, Jul 17, 2015 at 2:23 AM, Ben Maurer wrote:
> 
>> On Thu, Jul 16, 2015 at 9:07 PM, Martin Thomson wrote:
>>>
>>> Like I said, you can implement your proposed solution today, without
>>> writing any standards.  Sure, only Chrome supports it right now, but
>>> that's a whole lot more of the web than none of it.
>>>
>>
>> Using unique URIs to define resources is a common behavior to many sites
>> and is widely recommended in blogs/books/etc. It seems worth creating a
>> standard way to implement this recommendation that is far simpler than a
>> service worker.
>>
> 
> Agree!
> 
> But again, why not just changing the page reload behavior by some directive
> on the page reloaded, rather than changing the caching semantics of the
> cached objects? Changing the caching semantics to make a url absolutely
> permanent is dangerous as we discussed, you can freeze a page.

Because a) this is about revalidation (Ctrl+r) rather than reloading
(Ctrl+Shift+r) and b) revalidation also happens a lot from non-browser
client and middleware. The latter is very unlikely to have even looked
at the payload before trying its revalidation. If you put it in the
payload it effectively becomes an end-to-end feature only of use to
private caches (aka browser and closely related apps).

> 
> My proposal to just specify the reload behavior for subresources (disabling
> revalidation) on the page that causes the fetches looks a simple and less
> dangerous. Just makes the reload button same as clicking on the url bar and
> pressing enter again.
> 

If this were a feature only of use to browsers. I would agree with you.

But its also of potential use to shared/middleware caches for the same
purpose of reducing revalidations. Which means header solutions are much
preferrable over payload ones.

Amos