I'm running basic phalconphp app on php7.0, and I got this error:
"End of script output before headers: ea-php70"
I did many searches.
Additionally, whatever I choose cgi or suPHP as my PHP handler, the error is still there.
Any idea?
Related
I'm on network solutions apache server. On their setup page I chose to enable error logging. Nothing ever seems to appear in the log folder though. I suppose that could be good if I really have no errors. How could I create an error that should show up in the log folder so I can test it.
If you have enabled dynamic scripts, how about a script that dies or won't compile?
#!/usr/bin/env perl
die "This script intentionally produces HTTP 500";
I'm writing a Python CGI script and trying to test the behaviour of the system when I need to return Status: 500 Internal Server Error.
My script is something like that:
#!/usr/bin/env python3
print("Content-type: text/html")
print("Status: 500 Internal Server Error")
print()
When I run this script there is a report in apache access log with code 500, but it's not reported in the error log. I also don't get a "500 page" in the browser.
If an internal error is caused by some other means (e.g., a script that is not executable, or contains bad HTTP header) I do get the "normal" behaviour of internal server error.
It seems like apache is ignoring, somehow, the status returned from (my) CGI scripts. I've searched for an answer but couldn't find anything.
Just for clarity, CGI is working fine on this server in any other aspect.
Any thoughts? Am I missing something?
Thansk,
Amit
Answering to myself: it seems that I was barking up the wrong tree. Based on some clues and more empirical results, It seems that when passing a request to an external script (e.g. a cgi script, php etc) the apache server expects the external script to handle any error, and it's the responsibility of the external script's to return a document that includes the error code and an error message. The external script is also responsible to log the error (it's usually enough to print it to the standard error, and it'll be picked by apache and be written to its error log).
So, for example, if my cgi script needs to report an "Internal Server Error" it is not enough to return just the header (see in my question), but it should create and return the whole error message, in HTML format. In addition, it should print an error message to the standard error.
I haven't found an official source for that, but perhaps I somehow overlooked it.
Ive got a static client side site (html,css,js) on a LAMP server (although no mysql or php is being used), the only server side config is done by the .htaccess file and the setup of the server.
I want to test my error pages, is there a way to force a 500 error in a site setup as above ?
Oh my. Usually people want to avoid them! :-)
If you're running PHP 5.6.13 you could request a script with this content:
<?php function f(){f();}; f();?> which will segfault. But this is rather obscure.
Here's a fail-safe way: write a CGI script:
#!/bin/bash
exit 1
and call it.
I've seen hundreds of pages explaining how to create custom error pages in Apache 2 server. My question is different. I have a web application running in Apache (it is a ISAPI DLL, but it could also be a CGI executable). My application can handle internal server errors and generate a detailed error message (for instance, include a full stack trace), included in the response together with error code 500. AFAIK, Apache just let me use redirection in order to display custom error messages: http://httpd.apache.org/docs/2.2/custom-error.html
HTTP spec (RFC 2616 - section 10), not only allows but also recommend that detailed error message should be included in the BODY section of the response in case of error code > 500.
Link: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5
Seems that Apache won't let my custom error message go to the browser, and always replace it with its own internal error message and I believe that it is not the correct behavior, based on RFC 2616.
So my question is: Is there any setting in Apache server that will let my custom message go to the browser? Or, is there anything that can be done in my application that will instruct Apache to send my custom error message (something like some specific header field in the response)?
More on the subject:
When my ISAPI application returns error code 500, with other error information in the response body, Apache replaces it with its standard "500 Internal Server Error" message/HTML content, and inside Error.log file I can see the "useless" "Premature end of script headers" message. I'm deeply sure that my headers are fine, including the Content-Type field.
If I replace the 500 error code with any other server error code (e.g. 501) it works flawlessly and my response goes to the browser as is. The same header is sent to the Apache server, only the error code is different (501, instead of 500). With this test result in mind, one of these two must be true:
1- Apache requires some specific header field when status code is 500
2- Apache won't let custom error messages with status code 500 go to the browser.
I don't see any other alternative.
I think you're conflating two questions. You can generate a 500 response with a CGI script and include your custom body. Or you can override any 500 with any resource you want.
If you're failing to do the former, it's likely because of some subtle thing in the ISAPI interface between Apache and your module. Desk-checking the code says you should be able either set the pseudo
Status: 500
Header, or basically return any ISAPI error and end up with a 500 and your custom body.
Apache has two notions of a status code -- the one in the status line (r->status) and an error code returned separately from the module that handles the request (return HTTP_INTERNAL_SERVER_ERROR, return r->status).
When the former is used as the latter is when the custom error messages get lost. All of that happens in./modules/arch/win32/mod_isapi.c in Apache. Whatever is going on, it is ISAPI unique.
I'm attempting to build an error handling service for my CodeIgniter apps, and everything is logged as expected except parse errors. For example,
Parse error: syntax error, unexpected T_VARIABLE in /var/www/foo/web/app/controllers/foo.php
... will output and get logged by Apache under E_ALL. All other (non-parse) errors get passed to the log_exception extension I've written in /core/MY_Exceptions.php, and show up in CI's logs with PHP 5.2.17 and 5.3.6 (MAMP). Parse errors will display in Apache's native error log, but NOT in CodeIgniter's logs – they seem to miss CodeIgniter altogether.
How can I ensure that parse errors get picked up by CI? Am I missing something obvious?
This may help you: Why is codeigniter not logging error!
If the page is failing to load because of a parse error, then it'll
never execute
error_reporting(E_ALL);
so you script will never know to output the error. Edit your php.ini
file to make sure you have:
error_reporting = E_ALL
error_log = "/path/to/some/apache/writable/file"
Hope this helps.