Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 4124 invoked from network); 4 Jun 2010 15:10:25 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Jun 2010 15:10:25 -0000 Received: (qmail 18851 invoked by uid 500); 4 Jun 2010 15:10:24 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 18802 invoked by uid 500); 4 Jun 2010 15:10:24 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 18794 invoked by uid 99); 4 Jun 2010 15:10:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jun 2010 15:10:24 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates 72.32.122.20 as permitted sender) Received: from [72.32.122.20] (HELO chandler.sharp.fm) (72.32.122.20) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jun 2010 15:10:15 +0000 Received: from chandler.sharp.fm (localhost [127.0.0.1]) by chandler.sharp.fm (Postfix) with ESMTP id 4A70C238065 for ; Fri, 4 Jun 2010 10:09:55 -0500 (CDT) Received: from [10.254.254.254] (87-194-125-18.bethere.co.uk [87.194.125.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by chandler.sharp.fm (Postfix) with ESMTP id EF015780C9 for ; Fri, 4 Jun 2010 10:09:54 -0500 (CDT) Message-Id: From: Graham Leggett To: dev@httpd.apache.org In-Reply-To: <99EA83DCDE961346AFA9B5EC33FEC08B0407DE07@VF-MBX11.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: svn commit: r951222 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_disk_cache.c Date: Fri, 4 Jun 2010 17:09:53 +0200 References: <20100604001717.3A9762388999@eris.apache.org> <4C088EBB.1090509@apache.org> <7BC3EF30-FF15-457C-8A70-94E54219281A@sharp.fm> <99EA83DCDE961346AFA9B5EC33FEC08B0407DE07@VF-MBX11.internal.vodafone.com> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Checked: Checked by ClamAV on apache.org On 04 Jun 2010, at 4:15 PM, Pl=FCm, R=FCdiger, VF-Group wrote: > IMHO it does not (at least according to the comments and the code =20 > looks like > to follow these): This is only present on trunk, and this needs to be fixed too. The =20 problem we saw was in httpd v2.2. >> implementation (mod_disk_cache) to decide whether it wants to >> handle a >> 206 or not. >> >> mod_cache is not the place to fix this. It is entirely valid for a > > So you think that should be fixed in every single provider? Yes. Each provider should have the opportunity to cache a 206 if it so =20 wishes, as RFC2616 allows it. Remember that providers don't have to be =20= written by us. Any provider that chooses not to support a 206 should explicitly do =20 so, not rely on mod_cache to enforce a blanket ban on supporting 206 =20 response caching. > I am currently not convinced that any provider could cache a 206 with > the current mod_cache infrastructure. There was nothing in the original design for mod_cache that stopped a =20= provider trying to cache a 206. >> cache implementation to be given the opportunity to cache a 206, if > > Right, RFC2616 permits caching 206's. Regards, Graham --