- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 26 Aug 2009 22:30:08 +0200
- To: "Ford, Alan" <alan.ford@roke.co.uk>
- Cc: Robert Siemer <Robert.Siemer-http@backsla.sh>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org, Mark Handley <m.handley@cs.ucl.ac.uk>
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. However, many server implementations available today do not easily allow this on the wide scale you require without additions on the server, as they base ETag on other metadata that may differ between mirrors of the same object such as local file timestamp, filesystem inode numbers etc, not really taking the actual content of the object into consideration. Regards Henrik
Received on Wednesday, 26 August 2009 20:30:58 UTC