Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

> -----Original Message-----
> From: Mark Nottingham
> Sent: Thu, 17 Sep 2009 15:14:18 +1000
> On 16/09/2009, at 5:44 PM, Ian Hickson wrote:
> >
> >>> Given that HTML and Atom only allow one of each attribute, I think
> >>> we're far less likely to have bugs if we say that all but the first
> >>> occurrance of each attribute is just ignored.
> >>
> >> That's an artefact of their syntax (SGML and XML-based,
> >> respectively);
> >> do you expect people to use the same parsers?
> >
> > I expect implementations to use the same internal APIs, and those
> > APIs are
> > designed with the expectation of a single value for each attribute.
> > For
> > example, look for nsContentSink::ProcessLink() in the Mozilla
> > codebase.
> You're proving my point; Mozilla has nsContentSink::ProcessLinkHeader,
> which calls nsStyleLinkElement::ParseLinkTypes() (as does ProcessLink
> ()).
> That code does happen to only allow one rel value, but that's a bug,
> as the current specification of the Link header in RFC2068 and earlier
> clearly allow multiple rel attributes, and fixing it is a matter of a
> line or two.
> Nevertheless -- how do other people feel about restricting to one rel
> attribute in the Link header? Looking back at 2068, the BNF implicitly
> allows multiple rel values, but it isn't explicitly addressed in the
> prose, so Ian does have a point -- you could see it either way.

As long as a single rel value can still include multiple relation types I don't care much about limiting it to a single attribute. I am not sure what is the big gain here since we do allow multiple instances of other attributes like type and title.

I would get rid of the space delimited multi-values per a single rel and keep the multiple rels, but since HTML has that already it is not worth changing.


Received on Thursday, 17 September 2009 06:26:26 UTC