in reply to Re^2: a classic : 'Premature end of script headers' problem
in thread a classic : 'Premature end of script headers' problem

the script should be executable for the webserver. But, AFAIK if isn't, you won't get that error.

also: when you get the "premature end of headers" error, the webserver's error log can contain additional useful information (like what is received when it expects the header - generally the error is triggered by code that sends out messages/content before/while sending the header block)

update: you should never use &subname; without parentheses to call a subroutine unless you know why that's a special case, and if you're using parentheses it's always safe to leave off the &, so IMO it's generally a good habit leave off the & and use parentheses where it makes sense, like subname()

Replies are listed 'Best First'.
Re^4: a classic : 'Premature end of script headers' problem
by hmbscully (Scribe) on Sep 19, 2007 at 18:46 UTC
    The error log for my server just gives
    [Wed Sep 19 13:42:19 2007] [error] [client xxx.xxx.122.100] Premature end of script headers: consent.cgi, referer: http://mysite.com/ase-workkeys/employerconsent.html
    over and over again.

    As for the subroutine calling, I used to call them with the () and no &, but someone told me that was unnecessary if the subroutine did not return any values. What is the danger? I am asking seriously. Thanks.


    I learn more and more about less and less until eventually I know everything about nothing.
      The danger is that calling a sub as &subname; (with an ampersand, without parentheses) will pass on the current subroutine's @_ argument array. Which is almost never what you want to do.

      Using both parentheses and & sign is the same as just parentheses, and you can usually get away without parentheses too, provided the subroutine is defined before the call.

      did you mistakingly change ownership to root? for example, deleted and recreated consent.cgi? Also, is consent.cgi chmod 0755 ? do ls -lha /your/path/to/consent.cgi
        No, ownership is still to the correct account, not root.
        It is properly chmod'ed. That part I do understand.

        I learn more and more about less and less until eventually I know everything about nothing.