great stuff, Neil. newest draft adds ETags text from Henrik Nordstrom:
Metalink servers and their associated mirror servers SHOULD all share the same ETag policy, i.e. base it on the file contents (checksum) and not server-unique filesystem metadata. The emitted ETag may be implemented the same as the Instance Digest for simplicity. On Sep 18, 6:53 pm, "Neil M." <[email protected]> wrote: > 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-metalinkhttpupdated > > > 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 -~----------~----~----~----~------~----~------~--~---
