A fresh stale response
Alex Rousskov <rousskov@measurement-factory.com> Fri, 13 May 2016 00:26 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E73612B049 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 May 2016 17:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.917
X-Spam-Level:
X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xUMJX7W8Gv7m for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 May 2016 17:26:32 -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 14FB412B01E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 12 May 2016 17:26:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1b10re-0002qL-Cj for ietf-http-wg-dist@listhub.w3.org; Fri, 13 May 2016 00:21:58 +0000
Resent-Date: Fri, 13 May 2016 00:21:58 +0000
Resent-Message-Id: <E1b10re-0002qL-Cj@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 <rousskov@measurement-factory.com>) id 1b10rX-0002pF-Aq for ietf-http-wg@listhub.w3.org; Fri, 13 May 2016 00:21:51 +0000
Received: from mail.measurement-factory.com ([104.237.131.42]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rousskov@measurement-factory.com>) id 1b10rT-0007Co-NG for ietf-http-wg@w3.org; Fri, 13 May 2016 00:21:50 +0000
Received: from [65.102.233.169] (unknown [65.102.233.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id 1BCAAE078 for <ietf-http-wg@w3.org>; Fri, 13 May 2016 00:21:25 +0000 (UTC)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <57351E03.1090103@measurement-factory.com>
Date: Thu, 12 May 2016 18:21:23 -0600
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=104.237.131.42; envelope-from=rousskov@measurement-factory.com; helo=mail.measurement-factory.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=-0.792, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.416, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1b10rT-0007Co-NG c7a4112b0e2525bb822359dd94833dca
X-Original-To: ietf-http-wg@w3.org
Subject: A fresh stale response
Archived-At: <http://www.w3.org/mid/57351E03.1090103@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31643
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>
Hello, I need help navigating a pair of semi-conflicting RFC 7234 MUSTs. Imagine a cache that has a stored response A with a Date value X. The cache sends a conditional request to validate that cached response. The cache receives a 200 OK response B with a Date value of Y. If X <= Y, then the situation is clear -- A is stale and the cache should use B. What if X > Y? In other words, what if the cache receives a 200 OK response B that appears to be older (i.e., even more stale) than the response A the cache is trying to validate? Should the cache trust the sender's staleness decision or its own date comparison logic? * RFC 7234 section 4 says "a cache MUST use the most recent response (as determined by the Date header field)". That means A wins. * RFC 7234 section 4.3.3 says "the cache MUST use the full response [it just received]". That means B wins. * RFC 2616 section 13.2.5 says "If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, and the Date header in its existing cache entry is newer than the Date on the new response, then the client MAY ignore the response". That means A wins if A was fresh and B came from a cache. If I have to guess, I would use B if it does not have an Age header, boldly assuming that it is a first-hand response. Otherwise, use A. With more time/effort, revalidating with max-age=0 would be a good option (but it may result in the same conundrum). Is this a gray area, or did I miss a specific HTTPbis rule that resolves this conflict? Was the quoted RFC 2616 MAY replaced with something equally specific? If this is a gray area, what do you recommend? Thank you, Alex.
- Re: A fresh stale response Martin Thomson
- A fresh stale response Alex Rousskov
- Re: A fresh stale response Mark Nottingham