- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Wed, 16 Sep 2009 23:23:40 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>
> -----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. EHL
Received on Thursday, 17 September 2009 06:26:26 UTC