I just thought that it would be interesting to use MetaLinkHeader with 503 code(rfc2616 10.5.4 503 Service Unavailable). The current HTTP spec says that Retry-After header can be used with 503 to tell the clients when the server can fulfill the request. Instead of Retry-After, we presents Link header to the clients to navigate them to another server. I think this is more practical and convenient than using Retry-After if we have a mirror;Why we have to wait a single server when another mirror is available?
On 9月20日, 午前9:54, Ant Bryan <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
