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
Received on 2012-01-20 15:51:50 CET