You can clone with
Addressable::URI.parse("/%2E/").normalize.to_str.should == "/%2E/"
This issue probably requires a check-in with the IETF URI mailing list before deciding one way or the other.
I understand that it's been a long time ago, but still wanted to check in to see what's up with this issue? We've hit this bug in a bit different context and are not sure how to deal with it. Any chance this going to be fixed?
Could you elaborate on the issue you're hitting? A test case would be awesome.
Actually, now I'm not sure if our issue is related to this one. Here is our problem:
=> #<Addressable::URI:0x5648890 URI:http://foo.com/blah？>
=> #<Addressable::URI:0x564ed08 URI:http://foo.com/blah%3F>
Normalize call screws up a perfectly valid (AFAIU) unicode symbol and replaces it with a latin1 question mark.
It's doing the right thing actually. IRIs (unicode-friendly URIs) use unicode normalization form KC to limit phishing. NFKC tends to do perceptual codepoint conversions, like converting '？' to '?'. The solution here is not to normalize the URI if this is causing a problem, or to instead normalize components piecemeal. "http://foo.com/blah%ef%bc%9f" and "http://foo.com/blah%3F" are considered equivalent.
Added pending test for long-standing issue #8.