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: 43560
Status: rejected
Priority: 0/
Queue: CGI
People
Owner: MARKSTOS [...] cpan.org
Requestors: bkerin [...] fastmail.fm
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Feb 23 20:59:15 2009 bkerin [...] fastmail.fm - Ticket created
Subject: MIXING POST AND URL PARAMETERS doc section is somewhat misleading
Date: Mon, 23 Feb 2009 16:58:55 -0900
To: bug-CGI.pm [...] rt.cpan.org
From: "Britton Kerin" <bkerin [...] fastmail.fm>
This section looks like this: $color = url_param('color'); It is possible for a script to receive CGI parameters in the URL as well as in the fill-out form by creating a form that POSTs to a URL containing a query string (a "?" mark followed by arguments). The param() method will always return the contents of the POSTed fill- out form, ignoring the URL's query string. To retrieve URL parameters, call the url_param() method. Use it in the same way as param(). The main difference is that it allows you to read the parameters, but not set them. Under no circumstances will the contents of the URL query string interfere with similarly-named CGI parameters in POSTed forms. If you try to mix a URL query string with a form submitted with the GET method, the results will not be what you expect. What seems to happen for me is that when I load a url (hit return in the URL field in the browser) with a ?foo=bar addition, then param() gives me the param foo with value bar, at least according to CGI::Dump(). But if I then type in a form value and push a button that causes a submit, the url value parameter isn't in the list but the other form values are. I'm using the function interface rather than the $q->param() sort, not sure if that makes a difference. If not, it seems a bit strong to say that param() always returns the POSTed values, since it doesn't seem to do that when there aren't any POST values but there are url parameters. Britton
  Sun Jul 19 21:30:45 2009 MARKSTOS [...] cpan.org - Taken
  Sun Jul 19 21:33:59 2009 MARKSTOS [...] cpan.org - Correspondence added
On Mon Feb 23 20:59:15 2009, bkerin@fastmail.fm wrote: Show quoted text
> > This section looks like this: > > $color = url_param('color'); > > It is possible for a script to receive CGI parameters in the URL as > well as in the fill-out form by creating a form that POSTs to a URL > containing a query string (a "?" mark followed by arguments). > The param() method will always return the contents of the POSTed > fill- > out form, ignoring the URL's query string. To retrieve URL > parameters, call the url_param() method. Use it in the same way as > param(). The main difference is that it allows you to read the > parameters, but not set them. > > Under no circumstances will the contents of the URL query string > interfere with similarly-named CGI parameters in POSTed forms. If > you try to mix a URL query string with a form submitted with the GET > method, the results will not be what you expect. > > What seems to happen for me is that when I load a url (hit return in the > URL > field in the browser) with a ?foo=bar addition, then param() gives me > the > param foo with value bar, at least according to CGI::Dump(). But if I > then > type in a form value and push a button that causes a submit, the url > value > parameter isn't in the list but the other form values are. I'm using > the > function interface rather than the $q->param() sort, not sure if that > makes > a difference. If not, it seems a bit strong to say that param() always > returns the POSTed values, since it doesn't seem to do that when there > aren't any POST values but there are url parameters.
Thanks for the report. It seems the whole text of that section needs to be clearer that the behaviors described ther are only for the case when both POST and GET parameters are present. Could you suggest specific updates you'd like to see in the documentation to improve this? Mark
  Sun Jul 19 21:33:59 2009 The RT System itself - Status changed from 'new' to 'open'
  Sun Jul 19 21:34:15 2009 MARKSTOS [...] cpan.org - Subject changed from 'MIXING POST AND URL PARAMETERS doc section is somewhat misleading' to 'Needs Doc Patch: MIXING POST AND URL PARAMETERS doc section is somewhat misleading'
  Mon Aug 17 10:33:38 2009 rhesa [...] cpan.org - Correspondence added
I don't know. It seems pretty clear to me, but you have to realise it's talking about form submissions, and then pitches method="GET" against method="POST", assuming an action parameter with a query string. Compare these two forms: 1. POST form <form action="?foo=42" method="POST"> <input type="hidden" name="foo" value="84"> </form> If that's submitted to your form, the first paragraph kicks in. In this case you will see that: $cgi->url_param('foo') == 42 $cgi->param('foo') == 84 2. GET form <form action="?foo=42" method="GET"> <input type="hidden" name="foo" value="84"> </form> This is the second paragraph, and the result is: $cgi->url_param('foo') == 84 $cgi->param('foo') == 84 Since all parameters are coming from the query string in this case, this shouldn't be a big surprise, IMHO.
  Mon Aug 17 20:27:57 2009 MARKSTOS [...] cpan.org - Correspondence added
Rhesa, Thanks for your input. Based on that and the lack of a follow-up from the original requestor, I'm marking this request as rejected now, but am definitely open to further suggestions on improving the documentation. Mark
  Mon Aug 17 20:27:59 2009 MARKSTOS [...] cpan.org - Status changed from 'open' to 'rejected'
  Fri May 23 14:28:18 2014 The RT System itself - Queue changed from CGI.pm to CGI