p2 / p6: What is "cacheable"?

Mark Nottingham <mnot@mnot.net> Mon, 29 April 2013 12: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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F01121F9D88 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 05:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.624
X-Spam-Level:
X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2tgm76iQZ-9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Apr 2013 05:19:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61321F9D85 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Apr 2013 05:19:11 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWn1i-0008V2-Tu for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Apr 2013 12:17:50 +0000
Resent-Date: Mon, 29 Apr 2013 12:17:50 +0000
Resent-Message-Id: <E1UWn1i-0008V2-Tu@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWn1Z-0008Sq-My for ietf-http-wg@listhub.w3.org; Mon, 29 Apr 2013 12:17:41 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UWn1P-0001Fy-Kv for ietf-http-wg@w3.org; Mon, 29 Apr 2013 12:17:39 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D58A450A87 for <ietf-http-wg@w3.org>; Mon, 29 Apr 2013 08:17:09 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <2411783E-8B68-4BB4-86E4-7B89AD583022@mnot.net>
Date: Mon, 29 Apr 2013 22:17:05 +1000
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.390, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UWn1P-0001Fy-Kv be318251ec3af34cab9a4e348aec0164
X-Original-To: ietf-http-wg@w3.org
Subject: p2 / p6: What is "cacheable"?
Archived-At: <http://www.w3.org/mid/2411783E-8B68-4BB4-86E4-7B89AD583022@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17654
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>

p2 4.2.3 defines a method's cacheability as:

> Request methods are considered "cacheable" if it is possible and useful to answer a current client request with a stored response from a prior request. GET and HEAD are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable, though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses are defined in[Part6].

However, p6 section 3 prohibits caches from storing a response unless

> The request method is understood by the cache and defined as being cacheable

These seem to be incompatible; p2's "method cacheability" is defined in terms of whether a previously stored response can be used to satisfy the current request method, whereas p6 defines it in terms of whether responses to the method can be stored for future use.

The p6 definition (perhaps unsurprisingly) makes the most sense to me, and I think we should align that in p2 with it, adjusting the text in the methods themselves if required. 

We also seem to have a number of different types of cacheability defined right now; there's method cacheability, status code cacheability, and overall response cacheability.

While we could invent some new terms (e.g., pressing "storability" into service), I think we could improve things by just using "cacheable method", "cacheable status" and "cacheable response" consistently throughout the specs.

Finally, p2's section on status codes buries this at the end of 6.1 (under a large table):

> Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [Part6]; all other status codes are not cacheable by default.

This should be moved up (and changed to "cacheable status" as per above).

I think this issue is editorial, unless there's disagreement over what method cacheability is (Roy?)

Cheers,

--
Mark Nottingham   http://www.mnot.net/