Where would I see what the server is seeing?
I added that line and I saw no difference, either in the output or in the error logs.

---

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

Make that BEGIN { $|= 1; print "Content-Type: text/plain\r\n\r\n"; }, the $|= 1 part being important, the \r's likely not important (that part of the RFC is rarely a sticking point, thankfully).

- tye        

#!/usr/bin/perl 
# consent.cgi
BEGIN { use CGI::Carp 'fatalsToBrowser'; }

use strict;
use warnings;
use CGI qw(:standard);
use Fcntl ':flock';
# ......

# as a curiosity also.. 
my $iam = `whoami`;

open(STDERR, '>>', '/home/myself/errlog') or die($!);
warn("I am [$iam]");
[download]

bash # tail -f /home/myself/errlog

After that hold the shell window on one side, and run the script on the other to see the output real time

use already executes at the same time as BEGIN. So while moving CGI::Carp higher is good, there's no need to use BEGIN.

#!/usr/bin/perl 
# consent.cgi
use CGI::Carp 'fatalsToBrowser';

use strict;
use warnings;
use CGI qw(:standard);
use Fcntl ':flock';
...
[download]

Or at least it looks like you're mixing up $flatfile, $filename and $linename in several places.

also a couple of useless things that are in your code:

 @flatfields = ("$sys_time", "$consent", "$user_name", "$company", "$u
+ser_email");
[download]

 @flatfields = ($sys_time, $consent, $user_name, $company, $user_email
+);
[download]

And map{} does a local $_ already, so there's no need to do an explicit local $_ in your code.

So taking all that in account, you may want

$linename = join(",", map { s/"/""/g; qq("$_") } $sys_time, $consent, 
+$user_name, $company, $user_email);
[download]

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

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.

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?"

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.

This error means that your script does't write correct HTTP header (mostly because it's terminates before writing any header).

Possible reasons:

• you did't

  print "Content-Type: text/plain\n\n";
  [download]

  But you said it does't help
• Sometimes (in my experience) the shebang string get corrupted. I mean some bad (invisible) symbols occur in it (at the end). Try to rewrite shebang string.
• Also it maybe permission problem

So one way to find the problem is try to run your script at shell and show us script output. It will be perfect if you run script from your webserver user account.