Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: CGI Not Returning Parameter that's there

by linuxer (Curate)
on Mar 21, 2009 at 21:10 UTC ( #752296=note: print w/replies, xml ) Need Help??

in reply to 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? }

Your code:

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

could be rewritten like this:

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

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


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

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
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.

      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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://752296]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2023-02-06 12:28 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (34 votes). Check out past polls.