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