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
