Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 54511
Status: resolved
Priority: 0/
Queue: CGI
People
Owner: Nobody in particular
Requestors: heiko [...] wecos.de
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Feb 11 03:55:31 2010 http://wecos.pip.verisignlabs.com/ - Ticket created
Subject: CGI::url_param uninitialized value in hash
Not sure if it is worth to file a bug report, but I like it to have a "clean" error_log to quickly detect relevant things: calling url_param() with a query string like www.example.com?p1=1&&p2=2 cause an error: Use of uninitialized value in hash element at (eval 109) line 14. at (eval 109) line 14 I assume, adding: my($param,$value); for (@pairs) { + next unless defined($_); ($param,$value) = split('=',$_,2); into the url_param() will fix it. Cheers Heiko
  Thu Feb 11 04:02:51 2010 http://wecos.pip.verisignlabs.com/ - Correspondence added
Am Do 11. Feb 2010, 03:55:31, http://wecos.pip.verisignlabs.com/ schrieb: Show quoted text
> Not sure if it is worth to file a bug report, but I like it to have a > "clean" error_log to quickly detect relevant things: > > calling url_param() with a query string like www.example.com?p1=1&&p2=2 > > cause an error: > > Use of uninitialized value in hash element at (eval 109) line 14. > at (eval 109) line 14 > > I assume, adding: > > my($param,$value); > for (@pairs) { > + next unless defined($_); > ($param,$value) = split('=',$_,2); > > into the url_param() will fix it. > > Cheers > Heiko
next unless length($_); Are parameters without values allowed? i.e. p3 within: www.example.com?p1=1&&p2=2&p3&p4=4 so we have to check "value" too ??? for (@pairs) { next unless length($_); ($param,$value) = split('=',$_,2); $param = unescape($param); $value = unescape($value) unless defined($value); push(@{$self->{'.url_param'}->{$param}},$value);
  Thu Feb 11 04:02:52 2010 The RT System itself - Status changed from 'new' to 'open'
  Thu May 22 08:07:44 2014 LEEJO [...] cpan.org - Correspondence added
This issue has been copied to: https://github.com/leejo/CGI.pm/issues/71 please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.
  Fri May 23 14:28:06 2014 The RT System itself - Queue changed from CGI.pm to CGI
  Sat Jul 12 12:14:54 2014 LEEJO [...] cpan.org - Correspondence added
Lack of a value is valid whereas lack of a key *and* a value, which raises the warning, doesn't make sense (it's nothing). Lack of a *key* still parses, although again this doesn't make sense to me but no doubt something somewhere depends on this. Resolved: commit b8aa6dc4bf7ee6f13f2756dedca118a85f3d9b15 Author: Lee Johnson <lee@givengain.ch> Date: Sat Jul 12 18:03:44 2014 +0200 resolve #71 [rt.cpan.org #54511] - warnings on query params fixed by skipping any params that have an undefined key - that is to say the following query string: p1=1&&p2=2&=3&p4=4 will parse into: p1 => 1 p2 => undef '' => 3 p4 => 4 note that the secion of the query string with no key or value (&&) no longer raises a warning as we skip that bit due to there being no key or value defined, whereas the section of the string with a value but no key (=3) parses into '' => 3 as the returned value from split will be an empty string on the LHS of the delimiter. the RFC (http://tools.ietf.org/html/rfc3986#section-3.4) isn't to clear on the valid formats for the key=value pairs, although it is not uncommon to have a key but no value so we keep that behaviour Changes | 1 + Makefile.PL | 1 + lib/CGI.pm | 1 + t/request.t | 15 ++++++++++++++- 4 files changed, 17 insertions(+), 1 deletion(-)
  Sat Jul 12 12:14:56 2014 LEEJO [...] cpan.org - Status changed from 'open' to 'resolved'
  Sat Jul 12 12:18:39 2014 LEEJO [...] cpan.org - Correspondence added
Annnnd there's a misleading typo in the commit message, fixed: commit 78ffbc199d1ce1324b27b5470a7f9fbc785c17f7 Author: Lee Johnson <lee@givengain.ch> Date: Sat Jul 12 18:03:44 2014 +0200 resolve #71 [rt.cpan.org #54511] - warnings on query params fixed by skipping any params that have an no key value pair, that is to say the following query string: p1=1&&p2=2&=3&p4=4 ^ ^^ ^ ^ will parse into: p1 => 1 p2 => 2 '' => 3 p4 => 4 note that the secion of the query string with no key or value (&&) no longer raises a warning as we skip that bit due to there being no key or value defined, whereas the section of the string with a value but no key (=3) parses into '' => 3 as the returned value from split will be an empty string on the LHS of the delimiter. the RFC (http://tools.ietf.org/html/rfc3986#section-3.4) isn't to clear on the valid formats for the key=value pairs, although it is not uncommon to have a key but no value so we keep that behaviour