Here is also a test URL if you don't want to setup the server side but are developing a client:
http://www.nabber.org/projects/appupdater/metalink/Appupdater-1.2.1.exe The Link header will point you to a sourceforge URL for download. Neil Ant Bryan wrote: > http://tools.ietf.org/html/draft-bryan-metalinkhttp updated > > for anyone interested, you can try out Metalink in HTTP headers w/ > Neil's bits from here: > > http://metalinks.svn.sourceforge.net/viewvc/metalinks/checker/ > http://metalinks.svn.sourceforge.net/viewvc/metalinks/webconvert/ > (Python script to convert .metalink to Apache directives) > > On Sep 9, 3:31 am, "Neil M." <[email protected]> wrote: >> The HEAD request actually works well in my case and makes sense for >> any download application. Metalink Checker is already performing a >> HEAD request to see if the MIME Type transparent content negotiation >> is implemented on the server. I should be able to use this same HEAD >> request to grab LINK headers. After that it proceeds with a normal >> GET in any case. >> >> For Metalink HTTP with lots of mirrors (openoffice.org, for example) >> that header is going to get really big with all those Link headers. >> This is particularly bad if you are doing lots of partial file GET >> requests (segmented downloads). Is there a way that we can turn >> those on/off (whatever is inverse of default)? Maybe they are only >> sent if the "Want-Digest" header is used? The current RFC draft does >> not address this. Maybe that is a comment for the draft RFC for the >> LINK header? >> >> On Aug 28, 3:59 pm, Bram Neijt <[email protected]> wrote: >> >>> Hi all, >>> Personally, I don't believe in HTTP headers as mirror descriptors. One >>> of the main reasons to use mirrors is to keep the load of the primary >>> server down. If you want to keep the load down, then you should not >>> send the whole file to every user you encounter, but to get the mirror >>> list the user will have to hit the link. One way would be to only >>> allow a HEAD request, but that seems idiotic to me because there is no >>> way to make sure people would only use the head request. >>> I've yet to come up with a problem this additional header complexity >>> would solve. >>> Bram >>> On Fri, Aug 28, 2009 at 8:03 PM, Ant Bryan<[email protected]> wrote: >>>> here are my very rough ideas for Metalink in HTTP headers >>>> http://www.ietf.org/id/draft-bryan-metalinkhttp-00.txt >>>> briefly, it's: >>>> Link: <http://www2.example.com/example.ext>; rel="alternate"; >>>> Link: <ftp://ftp.example.com/example.ext>; rel="alternate"; >>>> 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= >>>> On Jul 28, 5:37 pm, Anthony Bryan <[email protected]> wrote: >>>>> this is similar to some of metalink's features, but done in HTTP headers. >>>>> ---------- Forwarded message ---------- >>>>> From: Henrik Nordstrom <[email protected]> >>>>> Date: Mon, Jul 27, 2009 at 11:03 AM >>>>> Subject: Re: HTTP Extensions for Simultaneous Download from Multiple >>>>> Mirrors >>>>> To: HTTP Working Group <[email protected]> >>>>> This draft made a bit of surprise appearance in the transport area >>>>> meeting today: >>>>> http://tools.ietf.org/html/draft-ford-http-multi-server >>>>> My initial reaction is lots of obvious overlap with other work and >>>>> misunderstandings of basic HTTP functions like ETag. >>>>> Basic motivation behind the work may be reasonable however. >>>>> I will try to catch the author for a more in-depth discussion shortly. >>>>> Other opinions? >>>>> Regards >>>>> Henrik >>>>> -- >>>>> (( Anthony Bryan ... Metalink [http://www.metalinker.org] >>>>> )) Easier, More Reliable, Self Healing Downloads > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
