Re: interoperability differences with RFC3986 section 2.3

Hi Chris,

On Thu, Aug 11, 2011 at 7:19 AM, Chris Weber <chris@lookout.net> wrote:
> I'm looking for feedback on this test case.  I imagine the browser behavior
> noted below has been well-known for many years, and I'm wondering - am I
> interpreting RFC3986 section 2.3 correctly when determining the pass/fail
> result of these tests.
>
> "For consistency, percent-encoded octets in the ranges of ALPHA
>   (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
>   underscore (%5F), or tilde (%7E) should not be created by URI
>   producers and, when found in a URI, should be decoded to their
>   corresponding unreserved characters by URI normalizers."
>
> Looking at "Test 1" hosted at:
>
> http://lookout.net/test/uri/rfc3986-2.3.php
>
> (FAIL) FF5         /%41%42%43/
> (FAIL) Safari 5.1  /%41%42%43/
> (PASS) IE 9        /ABC/
> (PASS) Chrome 13   /ABC/
> (FAIL) Opera 11.5  /%41%42%43/
>
> My "Test 1" was to observe the resultant HTTP request generated from a
> simple reference to the following URI included as both an /href and an
> /img/@src
>
> http://www.example.com/%41%42%43/
>

According to my understanding of RFC3986, your interpretation is
correct. Note though, that:
- the test page, as a URI producer, should not create such URIs; and
- saying that an implementation passes/fails this section means that
you assume they are using "Percent-Encoding Normalization" under
Section 6.2.2.2, which I understand they don't necessarily do, perhaps
due to legacy.

.wil