W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Identifying the Resource Associated with a Representation?

From: Mike Kelly <mike@mykanjo.co.uk>
Date: Tue, 9 Nov 2010 12:48:07 +0000
Message-ID: <AANLkTinQQ5fX6dNNhn6Gt7Un8U4SfJMN+u_neLFXD7H-@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, nathan@webr3.org, HTTP Working Group <ietf-http-wg@w3.org>
Ok, thanks for clarifying.

Regardless - it does sound here as though a 200 with C-L response to a
GET should be considered to have rule 4 applied. Correct?

Cheers,
Mike

On Tue, Nov 9, 2010 at 11:38 AM, Mark Nottingham <mnot@mnot.net> wrote:
> It's a matter of degrees; the worst that can happen with invalidation is that there will be a cache miss. If a cache were to use C-L to satisfy future requests at that URL, it would allow cache poisoning.
>
> Cheers,
>
>
> On 09/11/2010, at 10:18 PM, Mike Kelly wrote:
>
>> Ok - how does that leave the cache invalidation rule for C-L and
>> Location? Do the same concerns over trust not apply?
>>
>> Cheers,
>> Mike
>>
>> On Tue, Nov 9, 2010 at 1:22 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>>
>>> On 08/11/2010, at 3:33 AM, Mike Kelly wrote:
>>>>
>>>> Out of interest; has anyone explored the possibility of a specific
>>>> cache-control directive that could indicate that the cache conditions
>>>> apply to the Content-Location URI?
>>>
>>>
>>> The problem is one of trust; if you own http://example.com/~mike/a and I own http://example.com/~mark/b, you don't want my responses making asserting things about yours.
>>>
>>> What's interesting is that there's talk in a few different places (mostly security communities, e.g., WEBSEC and the W3C) about policy frameworks; this may provide something to hang these sorts of semantics off of as well.
>>>
>>> Cheers,
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
Received on Tuesday, 9 November 2010 12:48:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT