W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

RE: Multi-server HTTP

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>
Message-Id: <1251318608.2630.29.camel@henriknordstrom.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT