Re: [RFC] cache architecture

On 26.01.2012 08:26, Alex Rousskov wrote:
> On 01/25/2012 01:20 AM, Henrik Nordström wrote:
>> ons 2012-01-25 klockan 15:03 +1300 skrev Amos Jeffries:
>>
>>> We also need to enumerate how many of these cases are specifically
>>> "MUST purge" versus "MUST update". The update case is a lot more
>>> lenient
>>> to sync issues than purges are.
>>
>> The case which matters here is that update actions done by a user
>> should
>> be immediately visible by the same user after accepted by the
>> requested
>> server.
>>
>> i.e. POST/PUT/DELETE etc need to invalidate any cached
>> representation of
>> the requested URL or Content-Location of response when same host.
>
> The above matches my expectations but I do not think it matches Amos'
> point of view.

I think I understand what you are trying to get at as the problem. But
don't think we can claim it as a HTTP violation when all instances which
received request (or knowledge of it) do purge properly.

A cache/worker which is *completely* unaware of the POST/PUT/DELETE
having ever happened cannot be held accountable for the result.

We are wholly dependent on the server or client providing
cache-controls that workaround the sync issues. So long as those
controls and the purge are obeyed correctly *when received* I call it
compliant.

_compliant_, not necessarily good or workable. Just compliant.

In the same way that rejecting requests without Host: is compliant. But
not always workable. We have to go beyond the spec, maybe adding a
violation to make it work well. But that is all *above and beyond
compliance* rather than basic conformance to them.

>
>> Note: This do not really work well today when there is siblings
>> involved.
>
> And it will not work if we use non-shared caches in workers (without
> some additional mechanism to synchronize them, of course).
>

Agreed, we can work around spec limits. In fact have to.

Amos
Received on Thu Jan 26 2012 - 00:32:41 MST