jQuery - Ajax returning error 500 on some posts

Question

I have some Ajax that has been working on a live site, now it has stopped working. The Ajax should be returning a page but is returning a 500 error (internal server error).

The strange thing is I can navigate and post to the page the Ajax is calling, so the page is only not working via an Ajax call ($.post).

Another strange thing is it is working fine locally, but not live. Also all the other Ajax on the site is working.

Anyone have the foggiest what this might be? By the way it's all jQuery with CakePHP.

Edit:

The apache error logs are saying: "Premature end of script headers: php-script, referer..."

Edit 2:

It all happened when I switched the server over to SSL. It says above error and then "Port 80".

Answer 1

First off, this has nothing to do with jQuery, AJAX, POST, CakePHP, or HTTP headers. The complete error message is "Premature end of script", which means that the PHP process that Apache is using to run the PHP script terminated unexpectedly (i.e., before the PHP process finished its part of the Fast CGI protocol). This generally means that the PHP process crashed or caused a "segmentation fault".

PHP segmentation faults can be difficult to troubleshoot, and they should never happen; PHP should never crash. The reason why it is crashing could be due to a number of things. Maybe it is a simple fix, though.

The first thing that I would do is completely uninstall PHP and install the latest stable version. If you are running PHP 5.3 and Windows, then you should only use the VC6 binaries (the "VC6 x86 Thread Safe" package); the VC9 package will cause PHP to crash when used by Apache. Reinstalling might fix your problem because extension DLLs/SOs of older releases of PHP might still exist in your extensions directory on the live server.

If on Windows and using MySQL, the next thing that I would do is make sure that the MySQL bin directory is in the live server's Path. The reason for doing this is to make sure that libmySQL.dll can be "found" by the OS. You should be able to SSH into the live server, type mysql --help, and see the MySQL CLI client's usage message. Restart Apache if you add the MySQL bin directory to Path.

If both of these suggestions do not solve the problem, then please update your question with answers to the following:

1. Are you using a web host or does a company IT team manage a server for your use?
2. If using a web host, are you leasing a dedicated server?
3. What operating system are you running?
4. What version of PHP are you using?
5. What PHP extensions are being loaded?
6. Do you load a Zend extension?
7. Do you ever use dl?

UPDATE: With version 5.3.6 and later, the PHP project no longer releases "VC6" installers. The recommendation is to install a build of Apache HTTPD from Apache Lounge and use a "VC9" installer.

Answer 2

Check your apache and php error logs! it will be in there

---

The most common cause of this problem is the script dying before sending the complete set of headers, or possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of the "premature end of script headers" message. Even if the CGI runs fine from the command line, remember that the environment and permissions may be different when running under the web server. The CGI can only access resources allowed for the User and Group specified in your Apache configuration. In addition, the environment will not be the same as the one provided on the command line, but it can be adjusted using the directives provided by mod_env.

The second most common cause of this (aside from people not outputting the required headers at all) is a result of an interaction with Perl's output buffering. To make Perl flush its buffers after each output statement, insert the following statements around the print or write statements that send your HTTP headers:

{
    local ($oldbar) = $|;
    $cfh = select (STDOUT);
    $| = 1;
    #
    # print your HTTP headers here
    #
    $| = $oldbar;
    select ($cfh);
}

This is generally only necessary when you are calling external programs from your script that send output to stdout, or if there will be a long delay between the time the headers are sent and the actual content starts being emitted. To maximize performance, you should turn buffer-flushing back off (with $| = 0 or the equivalent) after the statements that send the headers, as displayed above.

If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call fflush() after writing the headers).

Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM directives. You may get the message if the CGI script was killed due to a resource limit.

In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of your CGI and cause the "premature end of script headers" message.

---

CPHP:

• http://cakebaker.42dh.com/2007/07/18/premature-end-of-script-headers-with-baked-views/

Answer 3

Taken from http://henrik.nyh.se/2007/04/premature-end-of-script-headers-for-cgi-can-be-directory-permissions

Other than the reasons outlined in the Apache FAQ, the error log message "Premature end of script headers" for a CGI script (in my case a Ruby script on Dreamhost) can also mean that the directory containing the script is world-writable.

So folder permissions like drwxr-xrwx can cause this error. chmod 755 mydir would change those permissions to drwxr-xr-x and all is well.

I suppose Apache/suEXEC takes issue with running stuff that any evil user can edit.

Is worth checking the directory permissions.

On a separate note, you say that the issue occurred when changing the site to use SSL, however the error mentions port 80. Port 80 is used for standard HTTP traffic however port 443 is used for SSL traffic - if traffic is going via port 80 there could be a server misconfiguration, an HTTP where there should be an HTTPS, or an issue with your certificate. I have seen similar errors occur when a certificate expires. Are both the URLs (the calling page and the script) using SSL?