Re: dont-revalidate Cache-Control header

Guille -bisho- <bishillo@gmail.com> Fri, 17 July 2015 23:14 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 8B9D31A911D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jul 2015 16:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JuzGdUoSYTgU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Jul 2015 16:14:41 -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 DDA6F1A910F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Jul 2015 16:14:40 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZGEmg-0004fv-Ip for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Jul 2015 23:11:14 +0000
Resent-Date: Fri, 17 Jul 2015 23:11:14 +0000
Resent-Message-Id: <E1ZGEmg-0004fv-Ip@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 <bishillo@gmail.com>) id 1ZGEmZ-0004f9-MR for ietf-http-wg@listhub.w3.org; Fri, 17 Jul 2015 23:11:07 +0000
Received: from mail-ig0-f171.google.com ([209.85.213.171]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <bishillo@gmail.com>) id 1ZGEmY-0003l4-Cy for ietf-http-wg@w3.org; Fri, 17 Jul 2015 23:11:07 +0000
Received: by igcqs7 with SMTP id qs7so47827855igc.0 for <ietf-http-wg@w3.org>; Fri, 17 Jul 2015 16:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qXFjchYe7cGXWy3G/9IkpKJ2PX0MJBAIkqhMtAOwSGA=; b=0ArMAA3x+s2JkhC4PrcOw5VPLbVqw3oqierfPBuvoWZ3G/k8VrFDfFMEVba2n8ipCV HBcmuDRTbBvbNCkbwv8ufKsAMK2SM8yu244TJu2tc4m2lcondx4J5PUXW44E6bIrrhCF MXvUzUGz8Kgu7hTJeiZy10NP6GrF+i4QUOkORpg6usybvaXBi6sNE62NzUza9F3eLU+N 5bBhh5/UhvbA5aTI/6pMEz1NER4NQq/Mp8puTsx2DSOysUrs5MHB1VNn4wHrn9oXto7W 0Lt/+Y3U35UOEicZ8cimhEZ63th6V8sNgZhcfLtPqtHc6e83wSFd9rHmVNa6/0YbLY1O bJLQ==
X-Received: by 10.50.78.232 with SMTP id e8mr912545igx.24.1437174640488; Fri, 17 Jul 2015 16:10:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.142.200 with HTTP; Fri, 17 Jul 2015 16:10:20 -0700 (PDT)
In-Reply-To: <55A941F6.90608@treenet.co.nz>
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> <55A941F6.90608@treenet.co.nz>
From: Guille -bisho- <bishillo@gmail.com>
Date: Fri, 17 Jul 2015 16:10:20 -0700
Message-ID: <CAMSE37uER6QkOu0sRvOC5ZK1c7jH0_CCffJPq_dpDiRo4UuaZQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e013c6a20ed3b23051b1a4b30"
Received-SPF: pass client-ip=209.85.213.171; envelope-from=bishillo@gmail.com; helo=mail-ig0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.818, 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: lisa.w3.org 1ZGEmY-0003l4-Cy 87b031bfe476cf250ed84c160e7d8011
X-Original-To: ietf-http-wg@w3.org
Subject: Re: dont-revalidate Cache-Control header
Archived-At: <http://www.w3.org/mid/CAMSE37uER6QkOu0sRvOC5ZK1c7jH0_CCffJPq_dpDiRo4UuaZQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29986
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>

>
>
> > 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.
>
>
Yeah, I agree.

What I don't see is how to easily prevent the potential issues if a url
that is not versioned is marked as static by a hack/mistake. The
implications are really dangerous. The idea proposed of limiting to
sub-resources does not apply well for non-browsers and middleware. What
should be the behavior for non browsers in that case? How do you plan to
know in middleware/non-browser clients when things are / aren't
subresources?

If there is a non-browser client that is revalidating content, it's
probably because is configured to do so, it can be changed to not do so if
someone really wants that. There is a must-revalidate header that they
should be obeying, and in theory if its not set and ttl of cache not
expired, they should not be doing those revalidations.

That's why I think that the problem with revalidations mostly affects to
browsers, and why my proposal makes sense.

-- 
Guille -ℬḭṩḩø- <bishillo@gmail.com>
:wq