On 1 April 2014 15:48, Jure Grabnar <grabna...@gmail.com> wrote: > Hi, > > I debugged code before writing the 1st patch and found out that if "type" > attribute is not present in v3.0, libmetalink completly ignores it (URL is > not present in resources!). > If you write "type" attribute in v4.0, libmetalink ignores it (only "type", > URL is still present in resources!). So you have to find out protocol type > from URL in v4.0.
But the type attribute is currently not used by wget. I cannot find any reference to it outside metalink.c. Anyway, IIUC, types like torrent, ed2k, etc. are not in the realm of wget. yousong > This was the main purpose of the 1st patch. > > > On 1 April 2014 03:20, Yousong Zhou <yszhou4t...@gmail.com> wrote: >> >> Hi, Jure. >> >> On 1 April 2014 03:46, Jure Grabnar <grabna...@gmail.com> wrote: >> > Hello, >> > >> > thanks for your feedback! I corrected the first patch. >> >> Then the 1st one is fine with me. >> >> I am not fluent with Metalink and libmetalink on how it handles the >> type attribute. In version 4.0 of the standard, there is no type >> attribute for metalink:url element, only metalink:metaurl has it. >> Though not explicitly using a word like "must" in version 3.0 of the >> spec, looks like type attribute is a required one there (See 4.1.2.4 >> of the 3.0 spec). > > > I thought so too, but if you take a look at 4.1.2.5 section of the v3.0 > spec, the last example shows that "type" attribute can be omitted. > >> >> If that is the case, then the metalink file is not a >> standard-compliant one if that attribute is missing. Maybe later >> people want a way to ignore those non-compliant metalink:url element. >> But let that be another story when the need actually came up. :) > > > Then libmetalink should be tweaked a bit, to allow non-compliant <url> > elements, because currently it just ignores them (v3.0). > Although, to be honest, they could just switch to v4.0, where "type" is > optional and properly parsed by libmetalink. :) > > Regards, > > Jure Grabnar > >