in reply to Re: Problem with internet explorer.Mozilla firefox,beonex,netscape ok.
in thread Problem with internet explorer.Mozilla firefox,beonex,netscape ok.

I think it was for have access to the directory... wrong... doesn't needed :) thanks server error log says...

malformed header from script. Bad header=</body></html>: say_hello.cgi, referer: http://localhost/cgi-bin/say_hello.cgi

  • Comment on Re^2: Problem with internet explorer.Mozilla firefox,beonex,netscape ok.
  • Download Code

Replies are listed 'Best First'.
Re^3: Problem with internet explorer.Mozilla firefox,beonex,netscape ok.
by nobull (Friar) on Mar 27, 2005 at 17:19 UTC
    sub start_parser { my @resp = (); if (!param()){ push @resp, &Modules::Htmlpage::make_header("Hello first page."); push @resp, &Modules::Htmlpage::make_first_page(); } elsif (param('get_in')){ push @resp, &Modules::Htmlpage::make_header("I say hello to you.") +; push @resp, &Modules::Htmlpage::make_top_content("home"); } push @resp, end_html; return @resp; }

    If param() is true (i.e. there are parameters in the HTTP request) and param('get_in') is false (i.e. there isn't a get_in parameter or is was '' or '0') then start_parser() will just return '</body></html>'.

    Fix it so that it returns an appropriate valid CGI response under these circumstances.

    BTW: Do you know what the special &-prefixed subroutine call syntax does? If not then don't use it. If so, why you think you need it?

    Update: Fixed spurious ! typo.

      Just to help the newbies, when you call a function just with &foo the values in @_ are used as arguments to the function. This leads to some weird results.

      So, when you just want to call a function, use foo().

      Alberto Simões

        Erm, yes and no. &foo; (with no parens) passes the caller's @_, whereas &foo(); (with empty parens) passes an empty argument list. The former also has the side-effect of ignoring any prototypes. See perldoc perlsub for more details.

        Thanks for helping this newbie :)

      !param() is true (i.e. there -> aren't <- parameters in the HTTP request).

      Maybe i should read better ;) &-prefixed subroutines...

        !param() is true (i.e. there -> aren't <- parameters in the HTTP request).

        Er, no I should have said one of:

        • param() is true (i.e. there are parameters in the HTTP request).
        • !param() is false (i.e. there are parameters in the HTTP request).

        Previous post now corrected

      !param() is true (i.e. there aren't parameters in the HTTP request)

      About &-prefixed .. it seems that a should read better ... :(