in reply to a classic : 'Premature end of script headers' problem

And what are the permissions of /home/account/cgi-bin/asewk ?

And owner.group ?

Lastly, consider getting a hosting account that runs suexec Here's one of my fav: http://angryhosting.com

  • Comment on Re: a classic : 'Premature end of script headers' problem

Replies are listed 'Best First'.
Re^2: a classic : 'Premature end of script headers' problem
by hmbscully (Scribe) on Sep 19, 2007 at 18:32 UTC
    What should they be? I'm just learning about apache permissions. This isn't a hosting account. These are my own dedicated servers. I am root (but I still do have tech support).
    I learn more and more about less and less until eventually I know everything about nothing.
[reply]
      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()

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
[d/l]
[select]
        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.
[reply]
[d/l]

      oh wow.. ok .. you've got it easy on one hand because you have full access.. and hard on another because you have full access.

      do this instead.. vim /usr/bin/debughttp (as root) 

      #!/bin/sh
# this is just an example
#tail -f /var/log/httpd/error_log
tail -f /var/log/httpd/ssl_error_log | sed 's/^.\+0.41\]\|\, referer.\
++\.cgi\|\?rm=\w\+//g'

# or just 
# tail -f /var/log/httpd/error_log

      [download]
      (you know how to set perms on that? chmod 0700, just you everything, everyone else nothing)

      Open a terminal and # debughttp forget the CGI::Carp 'fatalsToBrowser' crap.. get rid of all that, get rid of the open(STDERR, '>>' .. all that.

      Make sure you have the right path to your httpd error log

      call the script from your browser and enjoy the wonder that is POSIX.

[reply]
[d/l]
        Ok, wow. Yeah, I may have root, but I don't understand any of that, so I'm not going to run off and put that on my server until I can spend sometime trying to figure out what tail does.
        In Apache that user is set up to have the error log at /home/account/logs, is this not the httpd error log?
        Thanks.

        UPDATE: In the /var/log/httpd/suexec.log, I found this:

        [2007-09-19 14:00:05]: uid: (506/devpreview) gid: (506/506) cmd: conse
+nt.cgi
[2007-09-19 14:00:05]: command not in docroot (/home/acccount/cgi-bin/
+asewk/consent.cgi)

        [download]

        I assume this is a user account issue then and not my actual perl script?
        I learn more and more about less and less until eventually I know everything about nothing.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom