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

RE: Multi-server HTTP

From: Ford, Alan <alan.ford@roke.co.uk>
Date: Fri, 28 Aug 2009 12:38:05 +0100
Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808590692@rsys005a.comm.ad.roke.co.uk>
To: "Henrik Nordstrom" <henrik@henriknordstrom.net>
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>
Hi Henrik, all,

Thanks for the clarification, so it seems we could in theory define the
ETag for this specification to ensure it matches across servers. That
would remove the need for all except the Mirrors: header, and possibly
Multiserver-Version (so that the server knows it's talking to a
multiserver-capable client and thus the ETag is defined this way). If we
didn't mind a small delay, we could probably do away with that too and
say the client could infer capability by getting a Mirrors: header back
from a HEAD request first, and then deciding what to do (assuming the
connection can be kept alive).

Which brings me onto another thing about Mirrors: header. One of our
longer-term goals with this would be to somehow provide wildcarded lists
of mirrors, so that a client could immediately run off and fetch bits of
a website from many mirrors, potentially speeding up loading time
considerably, and providing an alternative method of load balancing.

However, I'm struggling to see a neat way of doing this reliably, since
we couldn't get checksums for every file on the first handshake (or if
all content was static we might be able to, but it's a big overhead).
Does anybody have any ideas as to a neat way of doing this? Best I can
think of so far is some sort of version number/(pseudo)hash of the
entire directory structure! 


> -----Original Message-----
> From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
> Sent: 26 August 2009 21:30
> To: Ford, Alan
> Cc: Robert Siemer; Mark Nottingham; ietf-http-wg@w3.org; Mark Handley
> Subject: RE: Multi-server HTTP
> 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
> > see that working quite well. Plus, this would solve the ETag issue
> > I mention (assuming I have understood correctly - nobody has yet
> > corrected me!), since in this case the client /is/ requesting the
> > 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
> object version, for example based on an hash of the object data. How
> servers compose ETag is outside of HTTP specification and a property
> the server implementation, only requirement HTTP places is uniqueness
> among versions or variants of the same URI. The base HTTP
> places no direct requirements on how ETag from different URIs relate
> 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
> 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
> same object such as local file timestamp, filesystem inode numbers
> not really taking the actual content of the object into consideration.
> Regards
> Henrik

Roke Manor Research Ltd, Romsey,
Hampshire, SO51 0ZN, United Kingdom

A Siemens company
Registered in England & Wales at:
Siemens plc, Faraday House, Sir William Siemens Square,
Frimley, Camberley, GU16 8QD. Registered No: 267550
Visit our website at www.roke.co.uk
The information contained in this e-mail and any attachments is
proprietary to Roke Manor Research Ltd and must not be passed to any
third party without permission. This communication is for information
only and shall not create or change any contractual relationship.

Please consider the environment before printing this email
Received on Friday, 28 August 2009 11:39:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC