- From: Anthony Bryan <anthonybryan@gmail.com>
- Date: Mon, 23 Nov 2009 15:08:16 -0500
- To: David Morris <dwm@xpasc.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Nov 11, 2009 at 5:48 PM, Anthony Bryan <anthonybryan@gmail.com> wrote: > On Tue, Nov 10, 2009 at 6:53 PM, David Morris <dwm@xpasc.com> wrote: >> >> >> On Tue, 10 Nov 2009, Anthony Bryan wrote: >> >>> On Sun, Oct 25, 2009 at 5:54 PM, Micah Cowan <micah@cowan.name> wrote: >>>> >>>> sec 2, para 2: >>>> >>>> Metalink servers are HTTP servers that use the Link header >>>> [draft-nottingham-http-link-header] to present a list of mirrors of a >>>> resource to a client. They MUST provide checksums of files via >>>> Instance Digests in HTTP [RFC3230], whether requested or not." >>>> >>>> To me, this implies that a server either is, or is not, a "Metalink >>>> server", and behaves as required for Metalink servers for any and all >>>> resources that it provides. I expect that in practice, a given server >>>> will usually be a "Metalink server" with respect to certain specific >>>> resources, and will fail to meet the requirements of a Metalink server >>>> with respect to other resources that are served. >>> >>> Exactly, thanks. Is this better? >>> >>> "Metalink servers are HTTP servers that use the Link header to present >>> a list of mirrors of certain specific resources to a client. They MUST >>> provide checksums of certain specific files via Instance Digests in >>> HTTP, whether requested or not. That is, Metalink servers are not >>> required to provide mirrors and checksums for all files, only certain >>> specific files." >> >> Uh ... no ... "certain specific ..." is not a clear phrase as it is very >> generic and and no correlation with the notion of a multi-server, etc. >> >> I think you want to define a metalink resource ... for example: >> >> "Metalink resources include a Link header >> [draft-nottingham-http-link-header] to present a list of mirrors of >> in the response to a client request for the resource. A resource >> checksums via Instance Digests in HTTP [RFC3230] must be included. >> >> Metalink servers are HTTP servers with one or more Metalink >> resources." > > Thanks, David. Here's what I've changed it to: > > "Metalink resources include a Link header > [draft-nottingham-http-link-header] to present a list of mirrors in > the response to a client request for the resource. The checksum of a > resource must be included via Instance Digests in HTTP [RFC3230]. > > Metalink servers are HTTP servers with one or more Metalink resources." The latest revision includes this and an optional dependency on Metalink/XML for partial file checksums, which could also be used for the whole mirror listing if we don't want them all in HTTP headers. I'm biased but I think that's the easiest solution for partial file checksums. Content-MD5 isn't an option. We could also send them in headers but that would be pretty verbose, or define a new format. I think repairing downloads is important, but not as many current metalink clients go through the work of adding this feature, even though it's available, so maybe the dependency on XML isn't too bad. I'd love to hear everyone's thought or other solutions. Other open issues: Would it make more sense to use qvalue-style policies to describe mirror priority, i.e. q=1.0 through q=0.0 instead of pri=1 ? -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads
Received on Monday, 23 November 2009 20:08:56 UTC