Resent-Date: Mon, 20 May 2013 01:46:03 +0000
Resent-Message-Id: <E1UeFAp-0002h3-TW@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <006D3C4B-6BBB-4172-A642-BD81AC85686F@mnot.net>
Date: Mon, 20 May 2013 11:45:25 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3797752C-7299-425D-941E-6FF08F8EC904@mnot.net>
References: <FAC047C9-0DD2-4159-8FF9-760BE3160B49@niven-jenkins.co.uk>
 <006D3C4B-6BBB-4172-A642-BD81AC85686F@mnot.net>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net;
 helo=mxout-07.mxes.net
Subject: Re: Caching 412 responses
Archived-At: <http://www.w3.org/mid/3797752C-7299-425D-941E-6FF08F8EC904@mnot.net>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

I'm closing this issue; if you still have a concern, please bring it up =
and we'll reopen.

Regards,


On 17/05/2013, at 1:26 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Ben,
>=20
> In the current model, the server *has* to make a 412 explicitly =
cacheable (e.g, with CC: max-age, as you do below) or otherwise usable =
(e.g., with CC: public) for an intermediary to store it, so I don't see =
how this is exploitable; the server shouldn't make those responses =
cacheable (and indeed, AFAICT none do).
>=20
> The same could be said about 413 (Request Entity Too Large), 415 =
(Unsupported Media Type), 416 (Requested Range Not Satisfiable), 428 =
(Precondition Required), and probably a few more. If someone wants to =
make these responses cacheable, they need to do the work to make them =
properly cacheable (by including Vary).
>=20
> Make sense?
>=20
> Regards,
>=20
>=20
>=20
> On 16/02/2013, at 9:57 PM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> =
wrote:
>=20
>> Colleagues,
>>=20
>> RFC2616 and the HTTPbis drafts allow an intermediary to cache a 412 =
response to a request with an If-Match header, if the response contains =
appropriate Cache-Control headers.
>>=20
>> My understanding of the specifications is that the intermediary is =
then within its right to serve the cached 412 response in response to =
subsequent GET requests that do not contain an If-Match header (see =
bottom of this mail for an example set of requests/responses that =
illustrate what I'm trying to describe).
>>=20
>> This seems problematic because if an attacker knows an origin returns =
cacheable 412 responses, the attacker could fill the cache with 412 =
responses for a set of URLs (from that origin) by making spurious =
If-Match requests it knows will return 412 responses, and those 412 =
responses would subsequently be served up to other clients instead of =
the 'real' response the origin would have given if the 412 was not =
cacheable or if the attacker had not poisoned the intermediary's cache =
with 412s.
>>=20
>> I was wondering whether this is a gap in the spec and cacheable 412 =
responses should have an explicit (or implicit?) Vary: If-Match semantic =
associated with them?
>>=20
>> Or, whether it is purposely the way it is and is a case of providing =
the rope and letting people hang themselves if they so choose (Origin =
servers can always add the Vary: header if they care about cache =
poisoning, intermediaries can always not cache 412 responses, etc.).
>>=20
>> An example (with only the relevant Headers included for compactness) =
of what I am talking about would be:
>>=20
>> First request:
>> GET /foo HTTP/1.1
>> Host: example.com
>> If-Match: "thisisnotanetag"
>>=20
>> HTTP/1.1 412 Precondition Failed
>> Cache-Control: max-age=3D900
>> ...rest of response...
>>=20
>>=20
>> Subsequent request:
>> GET /foo HTTP/1.1
>> Host: example.com
>>=20
>> HTTP/1.1 412 Precondition Failed
>> Age: 10
>> Cache-Control: max-age=3D900
>> ...rest of response...
>>=20
>> Thanks
>> Ben
>>=20
>>=20
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
>=20

--
Mark Nottingham   http://www.mnot.net/