Created attachment 495978 [details] curl 'https://mirrors.fedoraproject.org/metalink?repo=foo&arch=bar' Description of problem: Mirrormanager reports errors inside of an xml comment. This makes it impossible for yum to get at the content. Indeed, an xml parser returns an empty tree. If the error report were encoded in xml, yum could distinguish an error from a metalink.xml file and report the error to the user. Also, the valid repos: # repo=fedora-15, arch=i386 would be easier to use if they were ready to copy and paste: # repo=fedora-15&arch=i386 or # https://mirrors.fedoraproject.org/metalink?repo=fedora-15&arch=i386 Version-Release number of selected component (if applicable): The metalink attributes do not include the mirrormanager version: <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sat, 30 Apr 2011 11:54:56 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> yum-3.2.29-4.fc15.noarch How reproducible: Always. Steps to Reproduce: 1. $ curl 'https://mirrors.fedoraproject.org/metalink?repo=foo&arch=bar' Actual results: See attachment. Expected results: A query result element in every xml document returned. xml encoded error report. Additional info: Bug 700988 - Error: File /var/cache/yum/x86_64/15/updates-debuginfo/metalink.xml does not exist
(In reply to comment #0) ... > Expected results: > A query result element in every xml document returned. > xml encoded error report. ... Searched for examples of how this is done and found the SOAP Fault element: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) 5.4 SOAP Fault http://www.w3.org/TR/soap12-part1/#soapfault SOAP Version 1.2 Part 0: Primer 2.3 Fault Scenarios http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L11549
MM reports other faults in an xml comment: $ curl 'https://mirrors.fedoraproject.org/metalink?foo' <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sun, 01 May 2011 16:04:39 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <!-- # either path=, or repo= and arch= must be specified --> </metalink> $ curl 'https://mirrors.fedoraproject.org/metalink?path' <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sun, 01 May 2011 16:06:02 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <!-- # path = error: invalid path --> </metalink>
The Metalink Download Description Format http://tools.ietf.org/html/rfc5854 ... o metalink:metalink elements MUST contain one or more metalink:file elements. ... This would seem to preclude an empty metalink document. Also, they don't seem to mention a "files" (plural) element. <?xml version="1.0" encoding="utf-8"?> <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sat, 30 Apr 2011 11:46:06 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.o rg/mirrormanager"> <files> <file name="repomd.xml"> <mm0:timestamp>1304117214</mm0:timestamp> <size>4313</size> ... </file> </files> </metalink>
MM still uses the metalink 3.0 format, described here: http://www.metalinker.org/Metalink_3.0_Spec.pdf which does have a <files> element.
(In reply to comment #4) > MM still uses the metalink 3.0 format, described here: > http://www.metalinker.org/Metalink_3.0_Spec.pdf > which does have a <files> element. OK, thanks. 4.1.2 Required Body Elements 4.1.2.1 <files> Element, required sub-element of <metalink> <metalink> MUST contain one and only one <files>. A metalink 3.0 document cannot be empty. So, MM is returning an invalid metalink 3.0 document on a fault ...
(In reply to comment #5) ... > A metalink 3.0 document cannot be empty. > So, MM is returning an invalid metalink 3.0 document on a fault ... There will need to be an "error document": http://www.google.com/search?tbo=p&tbm=bks&q=xml+%22error+document%22&num=10 Also called a "fault document": http://www.google.com/search?tbo=p&tbm=bks&q=xml+%22fault+document%22&num=10
RFC 3117: On the Design of Application Protocols Marshall T. Rose November 2001 http://tools.ietf.org/html/rfc3117
Steve, can you give an example of what you'd think such a fault document should look like?
(In reply to comment #8) > Steve, can you give an example of what you'd think such a fault document should > look like? I'm very rusty on all this, but I would suggest starting by thinking about the protocol, rather than the message encoding. Something like this: MM Protocol Messages: Client Queries: Get Mirrorlist (current, metalink document) Get Repolist (proposed) Get Server Status (proposed) Server Replies: Mirrorlist (current, metalink document) Repolist (proposed) Server Status (proposed) Fault (proposed) All MM Protocol Messages would be encapsulated in an MM element[1], including the metalink document. The Fault message would be modeled after the SOAP fault message: http://www.w3.org/TR/soap12-part1/#soapfault http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L11549 If the client really needs the full repolist, it can respond to a Fault with a "Get Repolist" query. The Server Status message would be used to ping the server, inform the server of the MM version the client is assuming, and to report the MM version of the server to the client. This would allow the client and server to possibly agree on a protocol. In particular, the MM server should be able to support older client versions for backward compatibility. [1] SOAP uses an Envelope element that encapsulates a Header element and a Body element: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L1165
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping