- From: : Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
- Date: Thu, 27 Aug 2009 09:40:29 +0800
- To: ietf-http-wg@w3.org
- Cc: Alan Ford <alan.ford@roke.co.uk>, Mark Handley <m.handley@cs.ucl.ac.uk>
On Wed, 2009-08-26 at 22:30 +0200, Henrik Nordstrom wrote: > tis 2009-08-25 klockan 10:24 +0100 skrev Ford, Alan: > > Well that would certainly be a great solution for many use cases. If > > there was a distributed set of virtual hosts of a given server, I can > > see that working quite well. Plus, this would solve the ETag issue that > > I mention (assuming I have understood correctly - nobody has yet > > corrected me!), since in this case the client /is/ requesting the same > > resource from each IP address. > > ETag is per URI, but it is entirely fine for a specification like this > to require that the participating servers use the same ETag for the same > object version, for example based on an hash of the object data. How > servers compose ETag is outside of HTTP specification and a property of > the server implementation, only requirement HTTP places is uniqueness > among versions or variants of the same URI. The base HTTP specifications > places no direct requirements on how ETag from different URIs relate to > each other, but do hint that for objects having multiple URIs where > those URIs are equal it's expected the ETag would also be the same. “having multiple URIs where those URIs are equal” means that they do not have multiple URIs. And: -the HTTP spec only talks about when it MUST/SHOULD change, it can change in other cases at will (bashing the caches and/or making the DNS Round Robin use case weaker) -Apache is configurable on what it takes into account for the ETag, which helps into making that setup easier (use size and timestamp; and rsync for syncing) Robert
Received on Thursday, 27 August 2009 01:41:15 UTC