in reply to Compare URIs

URI has an eq function/method but it doesn't consider ...?joe=1&jack=2 and ...?jack=2&joe=1 to be equivalent. 
use strict;
use warnings;

use URI ();

my $base_uri = 'http://host/index.html';

my $uri1 = '/bob?joe=1&jack=2';
my $uri2 = 'http://host/bob?jack=2&joe=1';

$uri1 = URI->new($uri1)->abs($base_uri);
$uri2 = URI->new($uri2)->abs($base_uri);

print($uri1->canonical, "\n");
print($uri2->canonical, "\n");

print(URI::eq($uri1, $uri2) ? "equal" : "not equal", "\n");

[download]

Output:

http://host/bob?joe=1&jack=2
http://host/bob?jack=2&joe=1
not equal

[download]

Replies are listed 'Best First'.
Re^2: Compare URIs
by halley (Prior) on Oct 18, 2005 at 16:07 UTC
    To be more clear, one should not assume that the order or uniqueness of CGI parameters is arbitrary. Changing the order or enforcing the uniqueness may break some web applications. CGI itself has no rules about parameter ordering or uniqueness. Your application may add such rules or assumptions, but that's up to you.

    --
    [ e d @ h a l l e y . c c ]

[reply]

      I have read (in some spec, long ago) that web browsers may return fields in any order, which means the order of the CGI parameters *is* arbitrary. I can't find where I saw this, though.

      Update:

      If what I said was once the case, it is no longer. Quoting HTML docs (emphasis is mine):

      The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.

      So halley is correct. HTTP clients and HTTP proxies should consider ...?joe=1&jack=2 and ...?jack=2&joe=1 to be different. (HTTP servers can do whatever they want, of course.)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom