RE: Multi-server HTTP

fre 2009-08-28 klockan 15:45 +0200 skrev Daniel Stenberg:

> I think all this make me favour not a wildcard concept, but more a 
> list-concept where a site can list not only that "this object also exist HERE 
> and HERE" but then also "THESE OTHER OBJECTS also exist HERE and HERE" and 
> "THESE OTHER" would then be a list of (relative?) URIs somehow. But this 
> becomes awkward if the list of items is long.

I am in favor of wildcards and similar patterns. It's a one-way mapping,
mapping original URL to possible mirrors, not the other way around.

> Then we come to the concept of changing items. How long can a client assume 
> that the mirrors have the corresponding object? Would they need some kind of 
> cache control headers to specify that?

In the mirror-for-a-single-object based on response headers the mirror
better keep the object for as long as we tell the object fresh
(Cache-Control: max-age etc). HTTP does not define different freshness
for headers and the rest of the object, only on a response as a whole.
Adding new cache-controls for these headers is pretty useless as the
rest of the HTTP infrastructure (caches/proxies) will continue to use
the normal HTTP freshness definitions.

>  In the mirror-for-a-single-object case 
> I think we can assume that the mirror will have the object for at least a very 
> short while after the response said so but then it too gets this problem.

In my experience the problem in most mirror setups is the reverse, that
the mirror hasn't yet got the object or more troublesome to deal with
that the mirror has not yet updated of an existing object that got
changed.. The first is a rather trivial error condition to deal with, no
worse than when a mirror site isn't reachable (actually easier). The
latter is worse and will cause a bad download unless there is reasonable
means that protect from it (i.e. a common ETag and/or a hash Digest).

Regards
Henrik

Received on Friday, 28 August 2009 20:57:01 UTC