Re: Multi-server HTTP

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.
   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";
   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 MAY
   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

Received on Tuesday, 8 September 2009 01:20:40 UTC