Re: [httpbis] #432: Review Cachability of Status Codes WRT "Negative Caching"
Amos Jeffries <squid3@treenet.co.nz> Mon, 18 February 2013 02:45 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 56A0621F8A79 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 18:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.346
X-Spam-Level:
X-Spam-Status: No, score=-10.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkNmP3m5p6g6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 18:45:12 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC3321F8A6C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 18:45:12 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7Gie-00041P-4I for ietf-http-wg-dist@listhub.w3.org; Mon, 18 Feb 2013 02:44:40 +0000
Resent-Date: Mon, 18 Feb 2013 02:44:40 +0000
Resent-Message-Id: <E1U7Gie-00041P-4I@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1U7GiV-00040g-Vs for ietf-http-wg@listhub.w3.org; Mon, 18 Feb 2013 02:44:32 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1U7GiT-0000KO-UV for ietf-http-wg@w3.org; Mon, 18 Feb 2013 02:44:31 +0000
Received: from [192.168.1.103] (unknown [14.1.64.4]) by treenet.co.nz (Postfix) with ESMTP id 87B51E701B for <ietf-http-wg@w3.org>; Mon, 18 Feb 2013 15:44:04 +1300 (NZDT)
Message-ID: <51219570.3080504@treenet.co.nz>
Date: Mon, 18 Feb 2013 15:44:00 +1300
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <059.77033a1709a94099b974f5d7985e94b6@trac.tools.ietf.org> <1B168529-9ECB-4A4D-9EC2-190447DB6B72@mnot.net> <2B8C0176-F957-4B69-B264-99CF556BD858@mnot.net>
In-Reply-To: <2B8C0176-F957-4B69-B264-99CF556BD858@mnot.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.387, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U7GiT-0000KO-UV 7c5d9c48132ce5c567118513a88d6e1d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [httpbis] #432: Review Cachability of Status Codes WRT "Negative Caching"
Archived-At: <http://www.w3.org/mid/51219570.3080504@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16657
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 18/02/2013 1:12 p.m., Mark Nottingham wrote: > I haven't seen any discussion, and this is our last ticket (at least for the moment). Sorry I didn't get to reply to this earlier... You pointed at Squid as a widely used implementation doing negative caching. I would like to point out it in its current form it has been no end of trouble and we are actively advising people disable it. The usefulness seems to be greatest for reverse-proxy installations where the backend generation of errors is much more under control of the proxy admin. In general proxy installations it already commonly leads to the DoS vulnerability mentioned in the earlier thread. For now Squid only caches these if it generated the response itself (with a short TTL) or if the appropriate caching controls are present AND the admin explicitly enabled a negative caching timeout limiting the storage. > > So, I'll make a proposal; we should identify the following additional status codes as cacheable (i.e., eligible for using a heuristic to determine freshness, in the absence of explicit information); > > • 204 (No Content) +1. 200 is cacheable, therefor all 2xx SHOULD be cacheable or at least harmless when cached. > • 404 (Not Found) > • 405 (Method Not Allowed) > • 414 (Request URI Too Long) > • 501 (Not Implemented) +1. These ones make a lot of sense due to the long-term nature of the problems they are reporting. Even heuristic caching would seem to be safe. > • 502 (Bad Gateway) > • 503 (Service Unavailable) > • 504 (Gateway Timeout) These ones are often temporary conditions and where we have the most trouble with Squid despite the automatic re-try of alternative routes. A short glitch in DNS or routing can trigger them and DoS the caches entire client base for an overly-large timespan. It often does make sense to cache them, but only for very short time (seconds at most) and not in caches outside of the device which generated them. For devices with only one upstream route; the upstream outage is a problem for as long as the upstream sets cacheability on the reply. For devices with multiple upstream routes; the alternative routes may have shorter recovery times (mandatory decrease in cached time?) or be fully working for this request. Either way I am against caching these set without explicit Expiry information being present. > Note that I'm *not* proposing the following, even though they are negatively cached by some implementations, as I suspect doing so may cause interop problems: > > • 400 (Bad Request) > • 403 (Forbidden) > • 500 (Internal Server Error) > > Thoughts? 403 Forbidden might be cacheable when a Vary:WWW-Authenticate is also in the reply 400 and 500, I agree should be left non-cacheable by default so that their future 4xx/5xx sub-codes are not affected. /2c Amos
- Fwd: [httpbis] #432: Review Cachability of Status… Mark Nottingham
- Re: [httpbis] #432: Review Cachability of Status … Mark Nottingham
- Re: [httpbis] #432: Review Cachability of Status … Amos Jeffries
- Re: [httpbis] #432: Review Cachability of Status … Mark Nottingham
- Re: [httpbis] #432: Review Cachability of Status … Mark Nottingham