Re: dont-revalidate Cache-Control header
Ben Maurer <ben.maurer@gmail.com> Fri, 10 July 2015 22:22 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 170321A000F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Jul 2015 15:22:16 -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 q2xxRctz1CLr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Jul 2015 15:22:14 -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 DBA211A0010 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 Jul 2015 15:18:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZDga9-0008Gy-4j for ietf-http-wg-dist@listhub.w3.org; Fri, 10 Jul 2015 22:15:45 +0000
Resent-Date: Fri, 10 Jul 2015 22:15:45 +0000
Resent-Message-Id: <E1ZDga9-0008Gy-4j@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 1ZDga5-0008G7-VF for ietf-http-wg@listhub.w3.org; Fri, 10 Jul 2015 22:15:42 +0000
Received: from mail-la0-f42.google.com ([209.85.215.42]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <ben.maurer@gmail.com>) id 1ZDga4-0005Lq-0g for ietf-http-wg@w3.org; Fri, 10 Jul 2015 22:15:41 +0000
Received: by labgy5 with SMTP id gy5so120706423lab.2 for <ietf-http-wg@w3.org>; Fri, 10 Jul 2015 15:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dO6iT/MITAsAWh2tdjvH7tCWGQ0G0PqLLBq2k+SxI48=; b=t/sj0KInMuDw3EKtAIJ8fI+bjTYha6Mxm5xO/3MY0AuSIV/4JGH0x/skqMvSLPGN7u A+fjXkaN5LAeliOmp9+p+jXocDFQb0pSWVxy06dmuoNstgZ5CQ5+JXAq8nV0zyzSDD9j uwOmiZ5luWD4eXp4yN5lRqJEk+ONLNH8uXLS+N06iYzQNbTS3p1zQrgNXE0xWfN1Yv31 uOLFnoaplmySVgINA0wfZZul4+ga+rfXU48n05Hxc99SQxzhPlepxx8e9awk8/XQTo7M Nw6qA0V3PTyK5NKOWJaqjWk6UGML69KbDBKtR1BxrNjD/ltnnCVsDkpM/zaKAsEH2NpY ppFA==
MIME-Version: 1.0
X-Received: by 10.112.125.166 with SMTP id mr6mr21614918lbb.83.1436566513361; Fri, 10 Jul 2015 15:15:13 -0700 (PDT)
Received: by 10.25.163.147 with HTTP; Fri, 10 Jul 2015 15:15:13 -0700 (PDT)
In-Reply-To: <CACuKZqGzVJE36Ne3EZ8t02ZyFgwHdbNT0SOv4e0qyKMaqj=3dQ@mail.gmail.com>
References: <CABgOVaLHBb4zcgvO4NUUmAzUjNkocBGYY3atFA9iuYyoLaLQsA@mail.gmail.com> <CACuKZqGzVJE36Ne3EZ8t02ZyFgwHdbNT0SOv4e0qyKMaqj=3dQ@mail.gmail.com>
Date: Fri, 10 Jul 2015 15:15:13 -0700
Message-ID: <CABgOVa+x+=MGPAFudCN7tKz1cfoG5S0nhmhhDWwwkq=zOxgDJQ@mail.gmail.com>
From: Ben Maurer <ben.maurer@gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ilya Grigorik <igrigorik@google.com>
Content-Type: multipart/alternative; boundary="089e0122aecab9a9af051a8cb4b8"
Received-SPF: pass client-ip=209.85.215.42; envelope-from=ben.maurer@gmail.com; helo=mail-la0-f42.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 1ZDga4-0005Lq-0g 7e73a079849486abe34bfa48905fd098
X-Original-To: ietf-http-wg@w3.org
Subject: Re: dont-revalidate Cache-Control header
Archived-At: <http://www.w3.org/mid/CABgOVa+x+=MGPAFudCN7tKz1cfoG5S0nhmhhDWwwkq=zOxgDJQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29934
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 Fri, Jul 10, 2015 at 2:57 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote: > Questions: > > 1. MUST NOT seems too harsh. It'll put UAs that don't yet understand the > directive as non-compliant. And we can't be sure whether there could be > legitimate reasons for UAs to send conditional GET. > What about something like: The UA MUST re-use the request in response to normal page loading or reload requests discoverable by the average user. The UA SHOULD make non-conditional requests when specifically requested via advanced browser functionality (eg, developer tools, shift+refresh) My ultimate goal here is to set very clear expectations for UAs in handling this content. > 2. If the user views a subresource, e.g. an embedded image, directly as a > top resource, and the user refreshes UA, what should UA do? It's unlikely > that UA will refuse to oblige the refresh request. > Yes, I think it would be very reasonable for UAs to only implement this on subresources. This prevents a situation where a website accidentally sends down a dont-revalidate page in response to GET / and then the user can never recover from the error except for by clearing cache. If the accidental header occurs on a subresource the website can simply change the resource. 3. If UA requests an older version of a resource that the server no longer > keeps, how should the server respond? If the server returns the latest > version, it'll compromise the semantics of the URI. This requires clearer > specification. > What do you mean by request an old version? If the browser requests /X-v2.js but the current version os /X-v3.js, the server should respond to /X-v2.js with v2 of the javascript. If the developer has deleted that javascript, the server should return a 404. The developer should never re-use the /X-v2.js URI for other content. They could choose to re-upload /X-v2.js to the same URL in the future if they wanted to so long as it had the same content. Basically, if you have a URI /X-vY.js once you serve a dont-revalidate response on that URI you must forever either (1) serve the same content (2) serve an error. That said, your content doesn't necessarily have to be byte-for-byte identical, it just needs to be logically the same. For example, you might have a CDN that gzip encodes the file. If two nodes on the CDN gziped the file slightly differently that would be OK. The key is that you have absolutely no expectation that browsers will ever re-fetch a dont-revalidate URI once they have fetched it. -b
- 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