Thanks, Thomas. I hadn't meant to drop the list with my reply. You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around.
BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this *one* over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML <!-- comments -->. And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it. Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <[email protected]> wrote: > [you mailed off-list, was that intentional?] > > Andrew Arnott schrieb: > > > The difference is "<LINK>" might appear somewhere in the <BODY> of the > > page > > Not in a valid HTML document. :-) > > Of course you have to think about invalid ones as well, because browsers > accept them. > > But that doesn't have anything to do with whether there is a <HEAD> tag. > > The security implications are totally independent from having or omitting > HEAD tags. > > Look, it's perfectly clear at any point in the HTML text whether this point > belongs to HEAD or to BODY. The HEAD tags are irrelevant. > > Google even recommends omitting them: > http://code.google.com/speed/articles/optimizing-html.html > > I agree with Shade. It's sub-optimal security for OpenID RPs to try >> grokking HTML in the first place. I'm sure if you tried everything >> > > Of course parsing HTML is hell, but you have specified it. > > "legal", you'd likely find dozens of ways that RPs are imperfect. But >> since delegation is a relatively rare scenario anyway (hundreds of millions >> of OpenIDs out there today, only a few actually delegate since it's an >> advanced user scenario) I think it's very reasonable to put a few >> restrictions on it so that RPs can be more secure and written more easily. >> > > That doesn't change anything. > > Everything you're saying is absolutely right. But it doesn't have anything > to do with whether the HEAD element is surrounded by HEAD tags. > > My example is *valid*, by the OpenID specification. I have placed LINK > elements inside the HEAD element. That's what the OpenID spec demands. > > The implementation is *buggy*. Yes, that's a fringe case. I can't really > blame the author for not thinking about this. > > And the spec is fine by itself but could be improved for the benefit of > developers and users. > > So there are several ways to handle it: > > 1. The status quo -- don't do anything: perfectly okay, but probably many > more implementations will be buggy, without the developers even knowing > about the pitfall. > > 2. making clear in the spec that the HEAD element does not necessarily > correspond to HEAD tags and that a simple grep is *wrong*. > > 3. re-wording the spec so that it is clear that only a subset of HTML is > supported, requiring the HEAD tag(s). > > I'd prefer 2., just adding a non-normative note to the spec. > > Thomas >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
