Skip Menu |
 

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 81491
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: dwheeler [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: URIs not Equivalent with Differently Ordered Query Strings
Date: Tue, 27 Nov 2012 16:53:50 -0800
To: bug-libwww-perl [...] rt.cpan.org
From: "David E. Wheeler" <dwheeler [...] cpan.org>
Download (untitled) / with headers
text/plain 765b
Noticed while investigating this test failure: http://www.cpantesters.org/cpan/report/4a41cd2e-33d9-11e2-9885-9ffb7a36a9a6 I suspect that this is due to the hash order randomization in 5.17, since these tests only fail on 5.17. I think it is reasonable for query_form() to process things in whatever order it likes, but shouldn't two URIs with the same query params be equivalent, even if the params are in the string in different order? In other words, should this not emit "Yes"? perl -MURI -E 'say URI->new("foo.bar?b=1&o=1&a=s")->eq(URI->new("foo.bar?o=1&a=s&b=1")) ? "yes" : "no"' Of course these are different query strings: b=1&o=1&a=s o=1&a=s&b=1 But are they not functionally the same? { b => 1, o => 1, a => 's' } Thanks, David
Download (untitled) / with headers
text/plain 999b
On 2012-11-27 19:54:01, DWHEELER wrote: Show quoted text
> Noticed while investigating this test failure: > > http://www.cpantesters.org/cpan/report/4a41cd2e-33d9-11e2-9885- > 9ffb7a36a9a6 > > I suspect that this is due to the hash order randomization in 5.17, > since these tests only fail on 5.17. I think it is reasonable for > query_form() to process things in whatever order it likes, but > shouldn't two URIs with the same query params be equivalent, even if > the params are in the string in different order? > > In other words, should this not emit "Yes"? > > perl -MURI -E 'say URI->new("foo.bar?b=1&o=1&a=s")->eq(URI-
> >new("foo.bar?o=1&a=s&b=1")) ? "yes" : "no"'
> > Of course these are different query strings: > > b=1&o=1&a=s > o=1&a=s&b=1 > > But are they not functionally the same? > > { b => 1, o => 1, a => 's' } >
I think order matters here. Somebody could use a query string like foo.bar?ordered_array=1;ordered_array=2;ordered_array=3;ordered_array=4 and expect it to be ordered.
Subject: Re: [rt.cpan.org #81491] URIs not Equivalent with Differently Ordered Query Strings
Date: Wed, 11 Feb 2015 09:23:48 -0800
To: bug-libwww-perl [...] rt.cpan.org
From: "David E. Wheeler" <dwheeler [...] cpan.org>
Download (untitled) / with headers
text/plain 334b
On Feb 11, 2015, at 6:23 AM, Slaven_Rezic via RT <bug-libwww-perl@rt.cpan.org> wrote: Show quoted text
> I think order matters here. Somebody could use a query string like > > foo.bar?ordered_array=1;ordered_array=2;ordered_array=3;ordered_array=4
Yeah, I guess it depends on how URI represents it internally. You’re probably right, though. D
Download (untitled) / with headers
text/plain 485b
On Wed Feb 11 12:24:08 2015, DWHEELER wrote: Show quoted text
> On Feb 11, 2015, at 6:23 AM, Slaven_Rezic via RT <bug-libwww- > perl@rt.cpan.org> wrote: >
> > I think order matters here. Somebody could use a query string like > > > > foo.bar?ordered_array=1;ordered_array=2;ordered_array=3;ordered_array=4
> > Yeah, I guess it depends on how URI represents it internally. You’re > probably right, though. > > D
This issue is fixed as of URI 1.68 https://metacpan.org/changes/distribution/URI#L15
Download (untitled) / with headers
text/plain 749b
On Mon Aug 31 23:56:20 2015, OALDERS wrote: Show quoted text
> On Wed Feb 11 12:24:08 2015, DWHEELER wrote:
> > On Feb 11, 2015, at 6:23 AM, Slaven_Rezic via RT <bug-libwww- > > perl@rt.cpan.org> wrote: > >
> > > I think order matters here. Somebody could use a query string like > > > > > > foo.bar?ordered_array=1;ordered_array=2;ordered_array=3;ordered_array=4
> > > > Yeah, I guess it depends on how URI represents it internally. You’re > > probably right, though. > > > > D
> > This issue is fixed as of URI 1.68 > https://metacpan.org/changes/distribution/URI#L15
On further checking, this may not actually fix the issue. Your one-line still fails. Relevant test that was added to URI https://metacpan.org/source/ETHER/URI-1.68//t/sort-hash-query-form.t
Download (untitled) / with headers
text/plain 374b
On 2015-09-01 00:04:41, OALDERS wrote: Show quoted text
> On further checking, this may not actually fix the issue. Your one- > line still fails. Relevant test that was added to URI > https://metacpan.org/source/ETHER/URI-1.68//t/sort-hash-query-form.t
Yep, not fixed: Show quoted text
> perl -MURI -E 'say URI->new("foo.bar?b=1&o=1&a=s")->eq(URI->new("foo.bar?o=1&a=s&b=1")) ? "yes" : "no"'
no
Download (untitled) / with headers
text/plain 507b
On Tue Sep 01 20:22:06 2015, DWHEELER wrote: Show quoted text
> On 2015-09-01 00:04:41, OALDERS wrote: >
> > On further checking, this may not actually fix the issue. Your one- > > line still fails. Relevant test that was added to URI > > https://metacpan.org/source/ETHER/URI-1.68//t/sort-hash-query-form.t
> > Yep, not fixed: >
> > perl -MURI -E 'say URI->new("foo.bar?b=1&o=1&a=s")->eq(URI-
> > >new("foo.bar?o=1&a=s&b=1")) ? "yes" : "no"'
> no
Let's move discussion to https://github.com/libwww-perl/URI/issues/35


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.