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

Re: Multi-server HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 15 Sep 2009 13:06:57 +1000
Cc: Nicolas Alvarez <nicolas.alvarez@gmail.com>, ietf-http-wg@w3.org
Message-Id: <B3C9A183-D679-41C6-8570-0CA9E26D9072@mnot.net>
To: Anthony Bryan <anthonybryan@gmail.com>

On 08/09/2009, at 11:19 AM, Anthony Bryan wrote:

> Here's what I have now. More inclusive is good but I think someone
> else would be better at writing it than me.
> http://tools.ietf.org/html/draft-bryan-metalinkhttp
> Link Relation Type Registration: "duplicate"
>   o Relation Name: duplicate
>   o Description: Refers to an identical resource that is a
> byte-for-byte equivalence of representations.

Does this imply that each resource has exactly the same set of  
representations, or that when two resources share representations,  
those representations are duplicates?

>   o Reference: This specification.
>   o Notes: This relation is for static resources.  That is, an HTTP
> GET request on any duplicate will return the same representation.  It
> does not make sense for dynamic or POSTable resources and should not
>   be used for them.
> And here's the introduction (Content-MD5 is now mentioned):
>   MetaLinkHeader is an alternative to Metalink, usually represented in
>   an XML-based document format [draft-bryan-metalink].  MetaLinkHeader
>   attempts to provide as much functionality as the Metalink XML format
>   by using existing standards such as Web Linking
>   [draft-nottingham-http-link-header], Instance Digests in HTTP
>   [RFC3230], and Content-MD5 [RFC1864].  MetaLinkHeader is used to  
> list
>   information about a file to be downloaded.  This includes lists of
>   multiple URIs (mirrors), Peer-to-Peer information, checksums, and
>   digital signatures.
> Here's what it looks like:
>   Link: <http://www2.example.com/example.ext>; rel="duplicate";
>   Link: <ftp://ftp.example.com/example.ext>; rel="duplicate";
>   Link: <http://example.com/example.ext.torrent>; rel="describedby";
>   type="torrent";

Do torrents have media types yet?

>   Link: <http://example.com/example.ext.asc>; rel="describedby";
>   type="application/pgp-signature";
>   Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=
> And more description:
>   Metalink servers are HTTP servers that MUST have lists of mirrors  
> and
>   use the Link header [draft-nottingham-http-link-header] to indicate
>   them.  They also MUST provide checksums of files via Instance  
> Digests
>   in HTTP [RFC3230].  Mirror and checksum information provided by the
>   originating Metalink server is considered authoritative.
>   Mirror servers are typically FTP or HTTP servers that "mirror"
>   another server.  That is, they provide identical copies of (at least
>   some) files that are also on the mirrored server.  Mirror servers  
>   be Metalink servers.  Mirror servers MUST support serving partial
>   content.  Mirror servers SHOULD support Instance Digests in HTTP
>   [RFC3230].
>   Metalink clients use the mirrors provided by a Metalink server with
>   Link header [draft-nottingham-http-link-header].  Metalink clients
>   MUST support HTTP and MAY support FTP, BitTorrent, or other download
>   methods.  Metalink clients MUST switch downloads from one mirror to
>   another if the one mirror becomes unreachable.  Metalink clients are
>   RECOMMENDED to support multi-source, or parallel, downloads, where
>   chunks of a file are downloaded from multiple mirrors simultaneously
>   (and optionally, Peer-to-Peer).  Metalink clients MUST support
>   Instance Digests in HTTP [RFC3230] by requesting and verifying
>   checksums.  Metalink clients MAY make use of digital signatures if
>   they are offered.
> On Tue, Sep 1, 2009 at 3:08 AM, Mark Nottingham<mnot@mnot.net> wrote:
>> Totally; we just need to be crisp about it.
>> My inclination would be that if we can be more inclusive without  
>> making it
>> significantly more complex or risky, we should; otherwise, just do  
>> what's
>> needed.
>> Cheers,
>> On 01/09/2009, at 1:49 PM, Nicolas Alvarez wrote:
>>> Mark Nottingham wrote:
>>>> That's a good start, but it deserves a bit of discussion.
>>>> "byte-for-byte" implies that the bodes are the same, but what about
>>>> things like:
>>>> * Entity headers (e.g., Content-Type)
>>>> * Available content-encodings
>>>> * Whether partial content is supported
>>>> * Whether the same set of methods are supported (e.g., if A is a
>>>> duplicate of B, will POSTing something to either have the same  
>>>> effect
>>>> as on the other?)
>>>> I think the answer is that entity headers should generally be the
>>>> same, so the real question is whether we're talking about the  
>>>> relation
>>>> describing:
>>>> a) resources with duplicate representations (i.e., a GET on any  
>>>> of the
>>>> dups will return the same reps)
>>>> b) duplicate resources (i.e., any method will have the same effect)
>>>> If it's (b), we should consider whether the resources are in fact  
>>>> the
>>>> same "behind the curtains" (e.g., POSTing to A has the exact same
>>>> effect on the world as POSTing to B), or whether they may be in  
>>>> fact
>>>> separate systems (i.e., A and B have the same "interface", but  
>>>> POSTing
>>>> to A may affect a different part of the world to B).
>>> Well, we're talking about static GETable resources with a single
>>> representation. But I agree that if you make a Link relation,  
>>> you'd want
>>> it
>>> to be applicable to as many HTTP resources as possible... Or is it
>>> possible / reasonable to say "this relation doesn't make sense for  
>>> dynamic
>>> or POSTable resources and shouldn't be used for those"?
> -- 
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>  )) Easier, More Reliable, Self Healing Downloads

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 15 September 2009 03:07:39 UTC

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