Garret Wilson wrote on Fri, Jan 20, 2012 at 06:27:07 -0800: > On 1/20/2012 2:59 AM, Philip Martin wrote: > >1.7 has stricter rules for canonical URLs (from RFC 3986) than 1.6: > ... > >... > > - no lowercase % encoding: > > > > "http://host/repo/%C3%A5"; not "http://host/repo/%c3%a5"; > ... > >All the above URLs can be used with a 1.7 client because the client > >converts them to canonical form, but a 1.6 client will not do the > >conversion and will pass the non-canonical form to the server. A 1.7 > >server will sometimes reject such URLs: > > If I could throw my opinion in here even though I'm new... > canonicalization is a good thing in line with RFC 3986, which says, > "For consistency, URI producers and normalizers should use uppercase > hexadecimal digits for all percent-encodings." But rejecting > lowercase percent-encoded strings seems like a direct contradiction > of RFC 3986, which also says, "If two URIs differ only in the case > of hexadecimal digits used in percent-encoded octets, they are > equivalent." Rejecting a string that is a valid URI according to the > specification is going to bring interoperability headaches at the
We accept lowercase %-escapes in our interface to the outer world; but we're free to define our internal notion of 'canonical' however we want. We could easily decide that 'canonical' URLs may not use an uppercase E in %-escapes. We'd still be RFC compliant, since our public API requires all URI arguments to be passed via svn_uri_canonicalize() before being passed to any other function, and svn_uri_canonicalize() would accept uppercase E in %-escapes (and change them into lowercase). The problem we have is that the 1.7 server has a stricter notion of 'canonical' than the 1.6 client. > least. I personally don't like the lenience of the percent-encoding > case either, but that's what the spec says. > > Garret
