Comparing URIs broken: #normalized_query doesn't sort values

[mislav]

Two query strings can only be compared as strings if they are normalized and sorted.

u1 = Addressable::URI.parse '/path?foo=bar&baz=kuuq'
u2 = Addressable::URI.parse '/path?baz=kuuq&foo=bar'
u1 === u2  #=> false

The comparison here should result in true because query values order shouldn't matter.

Here's my monkeypatch: https://gist.github.com/832913

It's crude. I'd like some thoughts on this. I know that some server applications accept arrays in queries, eg.:

fruit[]=orange&fruit[]=apple

In this case, ordering is important. Maybe I should change my patch to just sort across keys and not across "key=value" pairs.

[sporkmonger]

I've been thinking about introducing a sorted_query field, but I'm pretty sure that using this behavior by default in the === method would be a mistake.

If implemented, it would use the OAuth normalization algorithm.

[mislav]

You didn't say why you think this would be a mistake.

I wouldn't close this so soon. This bit me in Webmock; it's a library where you stub a HTTP response by defining a URL and then, when that URL is requested, it returns a fake response. It compares URLs with the === operator, but was failing in some tests because of inconsistent query values ordering. Inconsistent ordering originated from the fact that hashes in 1.8 are unordered, and query values were populated from params in a hash.

If I had to get around this issue without patching Addressable, I would have to either ensure that query values are of consistent ordering when I build URIs (this would require a rewrite of a lot of my code; for instance I couldn't use URI#query_values=() anymore) or I would have to patch Webmock to do a custom URL comparison. The latter 'solution' kinda defeats the purpose of using Addressable in the first place.

[sporkmonger]

You should be able to use this form if you need order to be preserved:

[['key', 'value']]

Getting a consistent sort order is then as simple as:

{'key' => 'value'}.to_a