----- Ursprungsmeddelande -----
> If they have sync problems, they may violate HTTP. I am just doing my
> best trying to stay focused on the [local] cache architecture topic; I
> do not want to get into discussion about distributed hierarchies.
Exactly. HTTP spec is written for a consistent single-path forwarding path, not a mesh.
It's a matter of definition if a locally distributed cache is one logical cache or multiple independent caches.
> IMO, this just warns the implementer that the network complications
> (policy routing, load balancing, cache hierarchies, etc) may cause HTTP
> violations.
It was added after I pointed out that the invalidation is limited to a single forwarding path and won't work in cache meshes where the next request may travel a different forwarding path. It was agreed that the invalidation is best effort and can't be perfect in all conditions.
Ideally i would have liked to see that MUST downgraded to SHOULD but did not push on it. This because there is several cases where not following the MUST is the proper action (i.e. most cases involving an error response from the server).
> Clearly, we interpret the same specs differently. You see loopholes
> negating explicit MUSTs. I see a non-normative explanation why somebody
> cannot rely on the request path staying the same and a non-normative
> reference to a MUST.
Exactly. It's not loopholes, only notes reminding users of the protocol that the invalidation is a best effort when applied to the network as a whole and can not be guaranteed in all conditions.
You have to remember that the underlying spirit is to be strict on what you send but forgiving in what you receive. I.e. Your own implementation should follow specifications closely but accept that others may deviate slightly.
> I understand your point of view, but I have not seen anything in HTTP
> that supports a definition of compliance for a hierarchy of caches (with
> a single entry point) that differs from compliance of a single cache. I
> have not read the entire HTTPbis yet so it is possible that I will find
> it.
HTTP separates cache from proxy only loosely connecting the two. You can define this in any manner you like and be compliant to the wording of HTTP, even if not the spirit. But such appliaction of the specifications is against best recommendations on how to interpret rfc specifications.
> However, since we seem to agree that worker caches must be in sync, we
> can build the implementation on that consensus!
Yes. We need to keep that in mind in the design.
> It may be a good idea to polish HTTPbis if it indeed allows both yours
> and mine points of view to coexist even though they contradict each
> other.
It's a little late now for such adjustments. And not needed i think.
Regards
Henrik
Received on Thu Jan 26 2012 - 07:51:11 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 26 2012 - 12:00:13 MST