Re: CGI Not Returning Parameter that's there

How can you judge from the quoted log entry that parameter h is set? I only can see, that it was set in the referer, but I couldn't see it for the logged request?

Are you using strict and warnings? If not, please do it. If yes, I wonder, that there's no warning?

The following topics are not related to your problem, I think, but maybe give room for "optimization":

If you want to check alternative values of $function, use the if/elsif/else construct. It saves some time (maybe ;o). Otherwise each if will be checked (what for? If $function eq 'load', it cannot be $function eq 'mark').

if ( $function eq 'load' ) {
  # this
}
elsif ( $function eq 'mark' ) {
  # that
}
elsif ( $function eq 'foobar' ) {
  # something completely different
}
else {
  # any other stuff or something unexpected?
}
[download]

Your code:

my $junk;
($junk,my $headsent,my $headword) =  split(/[sw]/,$h);
[download]

could be rewritten like this:

# no $junk anymore and no doubled 'my' !
my ( $headsent, $headword ) = ( split /[sw]/, $h )[1,2];
[download]

Can you reproduce that issue in a little code example which can be tested by the monks to identify the issue?

Updates:

Is there a difference between the times when it works and when not (other url, special action, whatever?)?

Comment on Re: CGI Not Returning Parameter that's there Select or Download Code

Replies are listed 'Best First'.
Re^2: CGI Not Returning Parameter that's there by GrandFather (Saint) on Mar 21, 2009 at 22:40 UTC
A more important reason for deciding between `if ...; if ...; ...` and `if ... elsif ...` is to indicate intent. A string of if statements indicates that any combination of them may be true. An if/elsif chain indicates that only one may be true. Efficiency differences in this case are most likely trivial, but the difference in information conveyed between the writer and reader of the code is highly significant! True laziness is hard work	[reply] [d/l] [select]
Re^2: CGI Not Returning Parameter that's there by cormanaz (Deacon) on Mar 21, 2009 at 22:32 UTC
Well obviously it's not getting set, that's the problem. Yet it is getting passed from the client as indicated by the log, the variable is showing up in the parameter list, and the value is getting set most of the times I try the script.	[reply]
Re^3: CGI Not Returning Parameter that's there by linuxer (Curate) on Mar 21, 2009 at 22:57 UTC
Sorry, the shown log entry doesn't say anything about the parameter list for the request which produced that log entry. It shows your warning message (which indicates that parameter `h` wasn't set) with an empty string, a whitespace (or a possible undef in `$h`) at the position where `$h` should be interpolated... it's hard to guess, what caused that empty space between `h:` and `t:`. The log doesn't say anything about the actual parameter list for the logged request. What we see is the referrer's URL. That's the URL you were coming from (probably the URL you called before this logged one). And that URL contained parameter `h` in its query string (parameter list). If I'm so badly wrong on this, please enlighten me and explain that log format to me.	[reply] [d/l] [select]


go ahead... be a heretic
	PerlMonks