[OpenID] URL normalization issues

[Johnny Bufu]

On 23-Mar-07, at 11:11 AM, Gabe Wachob wrote:

> RFC 2616 is very clear about what to do: http://example.com and
> http://example.com/ should be equivalent. Again, see section 3.1.2  
> of RFC
> 2616.
>
> Furthermore, I'm not sure why we have to talk about a "normalized"  
> form. If
> all implementations comply with RFC 2616, section 3.1.2, then it  
> doesn't
> matter whether a component is presented with http://example.com or
> http://example.com/, it should do the same thing (ie it should  
> treat the two
> as equivalent).

For this issue, all we need to do is fix the examples in the OpenID  
spec; no impact here, just clarification.

> And I don't see why it matters that some web browsers want to redirect
> http://example.com/foo to http://example.com/foo/ - you should be  
> able to
> reconfigure a server not to do that, if it causes problems for OpenID.

Problem is, some RPs (LiveJournal most notably) assume *all* servers  
do that, even when they don't. As Drummond confirmed, there is no  
clean way of handling this, other than for OPs to maintain list of  
synonyms. The alternative would be to have OpenID identifiers that  
don't work on some sites, which would be ironical for LJ's case.

> I don't think we should create any new rules that differ from  
> section 3.1.2
> and the other equality rules in 2616 and 3986. The argument about  
> human
> usability (e.g. humans get confused between http://example.com/foo and
> http://example.com/foo/ ) doesn't persuade me to make an exception to
> equality rules. We've never made any other specific openid  
> processing rules
> based on human usability concerns.  And besides, if human usability  
> of HTTP
> URLs is an issue, you always have another choice of identifier ;-)
>
> In all seriousness, I think if everyone just follows the letter of  
> the RFCs,
> I don't see any real issue here. I think it's just a compliance  
> problem, not
> an OpenID spec problem.

Agreed - my questions were aimed toward how we implement / deploy to  
compensate when things are not 100% to the spec and significant  
enough not to ignore them.


Johnny