Thanks, Thomas. I hadn't meant to drop the list with my reply.<div><br></div><div>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.</div>
<div><br></div><div>BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this <i>one</i> 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.</div>
<div><br></div><div>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.<br clear="all">--<br>Andrew Arnott<br>"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<br>
<br><br><div class="gmail_quote">On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <span dir="ltr"><<a href="mailto:huehn@arcor.de">huehn@arcor.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[you mailed off-list, was that intentional?]<br>
<br>
Andrew Arnott schrieb:<div class="im"><br>
<br>
> The difference is "<LINK>" might appear somewhere in the <BODY> of the > page<br>
<br></div>
Not in a valid HTML document. :-)<br>
<br>
Of course you have to think about invalid ones as well, because browsers accept them.<br>
<br>
But that doesn't have anything to do with whether there is a <HEAD> tag.<br>
<br>
The security implications are totally independent from having or omitting HEAD tags.<br>
<br>
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.<br>
<br>
Google even recommends omitting them: <a href="http://code.google.com/speed/articles/optimizing-html.html" target="_blank">http://code.google.com/speed/articles/optimizing-html.html</a><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 <br>
</blockquote>
<br></div>
Of course parsing HTML is hell, but you have specified it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"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.<br>
</blockquote>
<br></div>
That doesn't change anything.<br>
<br>
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.<br>
<br>
My example is *valid*, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands.<br>
<br>
The implementation is *buggy*. Yes, that's a fringe case. I can't really blame the author for not thinking about this.<br>
<br>
And the spec is fine by itself but could be improved for the benefit of developers and users.<br>
<br>
So there are several ways to handle it:<br>
<br>
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.<br>
<br>
2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is *wrong*.<br>
<br>
3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s).<br>
<br>
I'd prefer 2., just adding a non-normative note to the spec.<br><font color="#888888">
<br>
Thomas<br>
</font></blockquote></div><br></div>