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)

History Show all quoted text
  Tue Nov 27 19:54:01 2012 dwheeler [...] cpan.org - Ticket created
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>
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
  Wed Feb 11 09:23:10 2015 SREZIC [...] cpan.org - Correspondence added
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.
  Wed Feb 11 09:23:11 2015 The RT System itself - Status changed from 'new' to 'open'
  Wed Feb 11 12:24:08 2015 dwheeler [...] cpan.org - Correspondence added
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>
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
  Mon Aug 31 23:56:20 2015 olaf [...] wundersolutions.com - Correspondence added
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
  Tue Sep 01 00:03:08 2015 ether [...] cpan.org - Status changed from 'open' to 'resolved'
  Tue Sep 01 00:04:41 2015 olaf [...] wundersolutions.com - Correspondence added
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
  Tue Sep 01 20:21:32 2015 dwheeler [...] cpan.org - Status changed from 'resolved' to 'open'
  Tue Sep 01 20:22:06 2015 dwheeler [...] cpan.org - Correspondence added
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
  Thu Mar 02 22:30:21 2017 olaf [...] wundersolutions.com - Correspondence added
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
  Thu Mar 02 22:30:27 2017 olaf [...] wundersolutions.com - Status changed from 'open' to 'resolved'