Re: Push and Caching

Martin Thomson <martin.thomson@gmail.com> Tue, 26 August 2014 21:19 UTC

Return-Path: <ietf-http-wg-request@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 406941A88D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 14:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.67
X-Spam-Level:
X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 jBjCFd9IFETD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 26 Aug 2014 14:18:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4C21A8891 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 26 Aug 2014 14:18:40 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XMO5a-0006xW-UG for ietf-http-wg-dist@listhub.w3.org; Tue, 26 Aug 2014 21:15:38 +0000
Resent-Date: Tue, 26 Aug 2014 21:15:38 +0000
Resent-Message-Id: <E1XMO5a-0006xW-UG@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XMO5H-0006we-AU for ietf-http-wg@listhub.w3.org; Tue, 26 Aug 2014 21:15:19 +0000
Received: from mail-lb0-f176.google.com ([209.85.217.176]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XMO5G-0002bK-JD for ietf-http-wg@w3.org; Tue, 26 Aug 2014 21:15:19 +0000
Received: by mail-lb0-f176.google.com with SMTP id c11so2060000lbj.7 for <ietf-http-wg@w3.org>; Tue, 26 Aug 2014 14:14:51 -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=IPxxjm1dTzDjiLU0ZcKLZYIPXy8iLZyZdb3Y459FDcs=; b=Ysca0Sg7mxadsBXD7qAieTZR33k1l6NQMx70mNfoBxEGesuK70PVJoApctXJLDVvid 7ztab2MZc5tIda5Mg7esoysoxPnqcpxdMn+FhalYDQXqFK40DEJjwjOtuHAiKglgelO5 JnQtSXaWm0xhbn0DmIEvzjHgeAyZolEGR3Z2HvajOLbatCYesQPd3LQ8Fvtmnd4XTMYC MScFF+Zv8g2Whk/Dcx4P49YIMbYUhbc/6wI4etD38r0Nv3CmSOv3zAkHml0Mc3RGLqp9 u+mHS7TVZv90bhVXQpa/qui7GwQ0cVe+Hc7e75JkPqwRilHoyi3OOViQW/rWFByp/pgZ 38ig==
MIME-Version: 1.0
X-Received: by 10.152.7.212 with SMTP id l20mr30102651laa.7.1409087691695; Tue, 26 Aug 2014 14:14:51 -0700 (PDT)
Received: by 10.25.166.75 with HTTP; Tue, 26 Aug 2014 14:14:51 -0700 (PDT)
In-Reply-To: <DE38D1FB-C9E1-441F-BDCE-9258714E0D96@gbiv.com>
References: <dc3d860ecb4b4d408a5ed0519a036e61@BL2PR03MB132.namprd03.prod.outlook.com> <CABkgnnWvKgyDcm-1jEKZUA2Qza9M46X+X_QybwuqRwvSUrTjNw@mail.gmail.com> <B6B89855-237F-44DA-B29C-2A3BB5CE0EED@mnot.net> <920b92b90a3c47ef8d450c903b83af40@DM2PR05MB670.namprd05.prod.outlook.com> <d94a3acceb954583a61b0118381df417@BL2PR03MB132.namprd03.prod.outlook.com> <CAOdDvNpa5WR4LJbsgQaBE3bTSAc+gXfYqCmV+zmUzE5b7+1a9A@mail.gmail.com> <CECA0C1A-E64C-443A-87AF-22BC66286F72@mnot.net> <CABkgnnXVJA3R4qhc__k4j+_LzeS7B24VxfCZwBSfywepEx=tKA@mail.gmail.com> <40d03e3bb1df480e808e64fa29048880@BL2PR03MB132.namprd03.prod.outlook.com> <CABkgnnX-0X+JZfFYhm18b=bLidaq_pqN5s-K0NBS28m-s6+9Kg@mail.gmail.com> <233C8C21-BF80-4E07-9717-56630085E192@mnot.net> <CABkgnnW9Uq5R1KvuTXuT=xUdX_pVWikyAOMp=ixJe+c0NRs4Lg@mail.gmail.com> <CAH_y2NHV_966DSX4yX-=tfDPUkk-obCXFbJnPifQpFb1KFjYDg@mail.gmail.com> <7d2fdc975fec4646b21e86620a834e72@DM2PR05MB670.namprd05.prod.outlook.com> <2C38B85E-7290-4AE3-A886-12A329DE449C@mnot.net> <D92F296B-3E9A-42B3-978C-AC319C072C60@mnot.net> <9C64D35C-49BF-47F7-8D72-EFA2DA546FEA@gbiv.com> <22238EC5-50F4-4611-9FED-39E3D7B67B10@gbiv.com> <CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com> <DE38D1FB-C9E1-441F-BDCE-9258714E0D96@gbiv.com>
Date: Tue, 26 Aug 2014 14:14:51 -0700
Message-ID: <CABkgnnXczU13DFW5B+dGeMVyqt9n_ZC6O334UHsGdktZt_HjQQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.217.176; envelope-from=martin.thomson@gmail.com; helo=mail-lb0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.734, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1XMO5G-0002bK-JD 49a863c0ff057731372a476b8116046e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Push and Caching
Archived-At: <http://www.w3.org/mid/CABkgnnXczU13DFW5B+dGeMVyqt9n_ZC6O334UHsGdktZt_HjQQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26748
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 26 August 2014 12:05, Roy T. Fielding <fielding@gbiv.com> wrote:
> I would expect them to push another.  Isn't that sufficient?

It might be.  Though you have to accept that the opportunity to push
might not reappear.

>> I'm a little leery of implying something about regular response
>> validity in this context.  I couldn't find anything concrete in RFC
>> 7234 about the period over which a response can be considered valid
>> once it arrives at the client.  The best I could find was: "A cache
>> need not validate a response that merely became stale in transit."
>
> Hmm, that effectively has the same meaning as what I proposed -- a
> pushed response can be considered in-transit until it is used.

If that is the case, that's writing a blank check.  Practically
speaking, that's how people use responses anyway: they use them when
they are ready to (which is usually as quickly as possible :).  The
point being not to prevent use, but to discourage reuse.

So if you are ok with that, then I am.  I still don't think that
binding to the connection lifetime is particularly useful though.