Hi Eran, hi list, On Fri, Jan 16, 2009 at 10:32:28PM -0800, Eran Hammer-Lahav wrote: > > The TAG has not officially ruled on this but individual members have > expressed the view that this is not consistent with HTTP. This came up > most recently in their review of Yadis, the discovery protocol used by > OpenID which uses the Accept header to request the descriptor instead > of the resource. There is no easy answer whether this is allowed or > not. > > One way to look at this is as views of the same resource. If there was > one representation that is complete (i.e. contains both the file being > downloaded and its metalink information), you can argue that a > metalink-only view is valid, as well as the file itself. But without > such unifying view, it is hard to claim that these are two > representations of the same resource. One is the resource, the other > is 'about' it. > > This gets philosophical very quickly... > > I have been reviewing this for the past few months for XRD, another > descriptor format (POWDER is yet another). My use case is more complex > than metalink because sometimes there is no resource, just metadata > (abstract resources). I have a few other requirements which led me to > write my discovery spec [2]. However, in the case of metalink, I think > the Link header should be enough for you needs since there is always > an HTTP URI you can perform GET on to find the Link header [1]. > > The downside is that it adds an extra round trip (one for the header, > another for the metalink document). There is no easy way around it > unless you are willing to use HTTP OPTIONS, etc. I wrote a blog post > [3] about this which is included in my draft. One thing sites with a > lot of downloads can do is use the Site-Meta options in my discovery > draft to declare a URI which can be used to request the metalink > document for other resource URIs. > > But again, I think it would be enough for metalink to simply use the > Link header [1].
Well, this is unfortunately missing the point of what we are doing. Avoiding the additional round-trip is key to put this to use in a high scalability setting. An additional round-trip is preclusive for me. Without getting too philosophical, I see no problems in using content negotiation to achieve this. Of all the options it seems to be the best and most suitable one, and I neither see a conflict with what it's meant for. And actually, doing an extra request to find out whether a Link: to a metalink could be provided sounds superfluous to me. What's more, when I do a GET request, I get a response with the resource anyway, so I (as a client) would rather have to do an extra HEAD request to discover such Link: headers. This would seem to me about as useful as, in language variant negotiation, if a web browser first does a separate request to discover the variants, and after choosing one does the real request. This just doesn't fly, would it? This might not make a noteworthy difference on a smallish server, but in large-scale environment, a doubling of requests makes a real difference. For me, this is not just theory. I have to deal with 15-40.000.000 requests per day on one server and I don't want to double those. And while server load is one thing in these matters -- client response latency is another. Far away clients would get notably worse response times when they have to do two requests. The latency of overseas connections, and even more of those to countries with bad Internet connectivity, satellite links etc. are always causing painful delays. And the additional bandwidth used would also not make it better. An additional Link header would be a good idea, though. I would happily support this. It could be an interesting option. Thank you very much for your thoughts and insight! > Let me know if I can help in any way. > > EHL > > [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03 > [2] http://tools.ietf.org/html/draft-hammer-discovery-01 > [3] http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html > > > On Jan 16, 4:13 pm, Anthony Bryan <[email protected]> wrote: > > Eran Hammer-Lahav and Mark Nottingham have informed me that using > > transparent content negotiation for serving a "description" of a file, > > and not an alternative version (like PNG vs JPG) of the same thing has > > been ruled against by the W3C TAG. > > seehttp://esw.w3.org/topic/FindingResourceDescriptions > > > > "Other ways of getting a description through HTTP > > * Use content negotiation. If you ask for RDF, you get the > > description. If you ask for something else, you get the thing > > described. (The TAG, TimBL, and others have pointed out that this > > contradicts web architecture, which requires that content negotiation > > choose among things that all carry the same information. That goes for > > CN between RDF and HTML as much as it does for CN between GIF and > > JPEG.)" > > > > the correct, web architecture complient way to do this is apparently > > the HTTP Link header: > > > > Link: <http://example.com/resource.metalink>; rel="describedby"; > > type="application/metalink+xml"; > > > > http://tools.ietf.org/html/draft-nottingham-http-link-header-03http://tools.ietf.org/html/draft-hammer-discovery-01 Peter -- Contact: [email protected] (a.k.a. [email protected]) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
