Bram, I view it as an experiment. we're not pushing it on anyone. but
who knows, we may stumble onto something?
Neil added support into checker in 25 new lines of code.
with very little effort, we have another IETF discussion going on
metalink. (what we need to discuss for a draft describing metalink XML
clients). as you can see from the appendix, I don't like it as much.
This draft, compared to the Metalink XML format [draft‑bryan‑metalink] :
* (+) Reuses existing HTTP standards without defining anything new
besides a Link Relation Type. It's more of a collection/coordinated
feature set.
* (?) The existing standards don't seem to be widely implemented.
* (+) No XML dependency.
* (?) Existing Metalink XML clients can be easily converted to
support this as well.
* (-?) Tied to HTTP, not as generic. FTP/P2P clients won't be
using it unless they also support HTTP, unlike Metalink XML.
* (---) Requires changes to server software.
* (-?) Could require some coordination of all mirror servers for
all features, which may be difficult or impossible unless you are in
control of all servers on the mirror network.
* (-) Requires server-side support. Metalink XML can be created by
user (or server, but server component/changes not required).
* (-) Also, Metalink XML files are easily mirrored on all servers.
Even if usage in that case is not as transparent, it still gives
access to users at all mirrors (FTP included) to all download
information with no changes needed to the server.
* (-) Not portable/archivable/emailable. Metalink XML is used to
import/export transfer queues. Not as easy for search engines to
index?
* (-) No way to show mirror/p2p geographical location (yet).
* (-) No checksums besides MD5/SHA-1 (yet).
* (-) Not as rich metadata.
* (-) Not able to add multiple files to a download queue or create
directory structure.
On Sun, Sep 20, 2009 at 6:15 AM, A. Bram Neijt <[email protected]> wrote:
>
> Hi,
>
> I didn't get the whole HTTP header, because I think that the server
> hosting the metalink should not host the files it links to (because then
> it can keep serving the metalink to clients even when all mirrors are
> busy or down).
>
> However, if you combine the HTTP header metalink with "Location", server
> error or other status codes it might be ok. Still, I'm not convinced
> that HTTP headers are a good solution and I don't think it is currently
> a good idea to start pushing another mirroring method onto the world.
>
> What are the big advantages over normal metalinks?
> What is the main goal of the HTTP header extension?
>
> Bram
>
>
> On Sat, 2009-09-19 at 23:19 -0700, Tatsuhiro wrote:
>> 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
>> >
>
>
>
> >
>
--
(( 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
-~----------~----~----~----~------~----~------~--~---
