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 -~----------~----~----~----~------~----~------~--~---
