W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: draft-bryan-metalinkhttp-18.txt

From: Anthony Bryan <anthonybryan@gmail.com>
Date: Tue, 23 Nov 2010 02:10:18 -0500
Message-ID: <AANLkTi=3=bvhATUP1FjTo-TTHB1kwU=-ADELzCRS1cAe@mail.gmail.com>
To: Peter Pöml <Peter@poeml.de>
Cc: ietf-http-wg@w3.org
On Sat, Sep 25, 2010 at 10:29 AM, Peter Pöml <Peter@poeml.de> wrote:
> Hi,
>
> a few thoughts regarding version 18 of http://tools.ietf.org/html/draft-bryan-metalinkhttp
>
>> 2.  Requirements
>>    [...]
>>    Metalink servers are HTTP servers with one or more Metalink
>>    resources.  Mirror and cryptographic hash information provided by the
>>    originating Metalink server MUST be considered authoritative.
>>    Metalink servers and their associated mirror servers SHOULD all share
>>    the same ETag policy (ETag Synchronization), i.e. based on the file [...]
>
> Regarding sharing an ETag policy, I think the wording could be relaxed. Some mirror servers might serve only FTP, and wouldn't support ETags then. In addition, from current experience with mirror networks it seems not too realistic to me to get mirrors share a policy. Of course, it is still a good idea.

other people have brought that up...reality is a good thing to consider :)

how about:

"Metalink servers and their associated mirror servers are RECOMMENDED
to all share the same ETag policy (ETag Synchronization),..."

> In the next paragraph:
>
>>    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.  HTTP mirror servers SHOULD share the same ETag policy as
>>    the originating Metalink server.  HTTP Mirror servers SHOULD support
>>    Instance Digests in HTTP [RFC3230].
>
> I'm not sure if the requirement to serve partial content should be obligatory. I know that some current mirrors don't "like" it, and I am in favor of ignoring them. But the crucial point is that any client that expects a server to support byteranges needs to expect the worst, which is that the server ignore the byterange header, starts to send the whole file and doesn't stop. Any client needs to be able to deal properly with this situation anyway, because in HTTP/1.1 it is legal to run a webserver with support for partial responses switched off. And I wonder about the need to require handling of partial requests also regardless of that: There are often small files that can sensibly be handled without partial responses. Of course, with very large files the situation is quite different, and it might not make sense at all to go without partial responses. So I'm not sure which is the best general recommendation here.

yes, it was a little black & white before. let's make it a recommendation?

"Mirror servers are RECOMMENDED to support serving partial content.
HTTP mirror servers are RECOMMENDED to share the same ETag policy as
the originating Metalink server. HTTP Mirror servers are RECOMMENDED
to support Instance Digests in HTTP"

> Next paragraph:
>
>>    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 mirror becomes unreachable.  Metalink clients SHOULD
>>    support multi-source, or parallel, downloads, where portions of a
>>    file are downloaded from multiple mirrors simultaneously (and
>>    optionally, from Peer-to-Peer sources).  Metalink clients MUST
>>    support Instance Digests in HTTP [RFC3230] by requesting and
>>    verifying cryptographic hashes.  Metalink clients MAY make use of
>>    digital signatures if they are offered.
>
> The statement that "Metalink clients MUST support HTTP and MAY support FTP, ..." implies that such a client might support *only* HTTP. A Metalink server might happen to provide only links to FTP mirror servers, though. So in fact, either the Metalink client should be required to support all protocols that the Metalink server might include, or the Metalink server needs to include at least one URL of each protocol. The latter would seem most sensible to me. The former would seem more realistic to me though, especially if we assume that a Metalink client supports HTTP and FTP anyway, and a Metalink server will always use at least one of these protocols in practice. Interesting nitpick, and maybe not a real-world problem; I would think that it has not caused anyone a problem up to now.

good nitpick :) I haven't heard of any problems so far...we do want to
allow Metalink clients that might be HTTP only.

here's some relaxed text:

"Metalink clients MUST support HTTP and are RECOMMENDED to support
FTP. Metalink clients MAY support BitTorrent, or other download
methods. Metalink clients are RECOMMENDED to switch downloads from one
mirror to another if a mirror becomes unreachable. Metalink clients
are RECOMMENDED to support multi-source, or parallel, downloads, where
portions of a file can be downloaded from multiple mirrors
simultaneously (and optionally, from Peer-to-Peer sources). Metalink
clients MUST support Instance Digests in HTTP [RFC3230] by requesting
and verifying cryptographic hashes."

the originating Metalink server will be HTTP, even if all alternate
download locations are only FTP or only bittorrent or only ed2k.

how about a sentence along the lines of "If a Metalink client does not
support certain download methods (such as FTP or BitTorrent) that a
file is available from, and there are no available download methods
that the client supports, then the download will have no way to
complete."

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
Received on Tuesday, 23 November 2010 07:10:49 GMT

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