For some reason, I get a HTTP 330 error whenever a PHP error is printed. This didn't use to happen, but since we had to restore our PHP application from a backup due to a server failure, it does. During that restoration, we switched over from using Apache to nginx + fastcgi. However, I'm also running the application locally, and I'm noticing the same issue on Apache, but only when using php 5.3.X. The application used to run on 5.2.11.
Has anyone encountered anything like this before? The only thing that googling has brought up is that maybe the PHP errors are sent using one encoding, and the rest of the content is sent gzipped, but I have no idea how to fix that - if it even is the problem.
Please ask if you need any more information. I'm not quite sure what information I could provide you with that would be helpful.
Enabling zlib compression in php.ini (zlib.output_compression = On) and then removing any ob_start("ob_gzhandler"); from the scripts seems to have solved the problem.
Related
Since about a week I've got a very strange caching problem. I did not make any changes I know of which could possibly lead to this problem.
It happens using:
PHP 8.1.9
Apache 2.4.48 or the built-in symfony web server
PHPStorm or notepad++
symfony or just plain PHP
Firefox or Edge
My output gets cached somehow. I can completely destroy the PHP code or rename/delete files -> still displayed correctly. Some time later it finally refreshes and displays the errors. The errors themselves don't get cached. Fixing them immediately returns the script to the expected behaviour. I've already disabled caching inside Firefox (in the settings and setting disk.cache.enabled to false), but it happens with Edge, too.
The only common thing my experiments share is the PHP version/installation, it probably does not have to do anything with Apache, symfony or the browser.
Any ideas?
I've found the answer.
Somehow opcache.revalidate_freq inside the php.ini was set to 200 and zend_extension=opcache enabled. I've never changed this manually. Would be interesting to find out what caused the change.
Bit of an odd one, but my development activity has been crippled by the loss of error messages in my DevTools. It was working yesterday, and from what I can see nothing on my system has changed.
The issue isn't browser related as it's impacting Chrome, FireFox and Edge; none of them display errors any more:
I saw in another SO question that someone had xDebug installed which was apparently caused this same issue for many folks. I also had it installed and believe I have removed it completely (perhaps there are remnants of its config somewhere?). Unfortunately I'm no better off from removing it.
Now that I can safely say the issue isn't browser related, I guess it can only be either my PHP config or Apache(WAMP) config?
The following PHP functions are compiled on my development environment, but I also wrote them at the top of my broken script for good measure and it made no difference.
error_reporting(E_ALL);
error_reporting(-1);
ini_set('error_reporting', E_ALL);
PHPInfo() confirmed that I'm showing and logging PHP errors also:
I got a little fed up so I uninstalled WAMP64 and installed the latest version (I know, taking a sledgehammer to crack a nut...) and it hasn't helped.
Any ideas?
I have a server in the office that's used as a development server. It's running Centos 7 with Apache, PHP and MySQL.
Randomly some web applications on the server has stopped returning a response, and upon inspecting the Apache error log, I'm seeing this error when no response is received;
zend_mm_heap corrupted
I've done some research and understand this has something to do with Zends memory management, but I don't seem to be able to find a way to resolve the issue.
I have checked my php.ini file, and cannot see any reference to APC so don't believe it's causing the issue.
The server was running fine, and it's pretty random that this has started, I don't believe we've changed anything on the server to cause the issue.
This error appears across multiple projects, so I confident that it's not project specific and more something relating to the server/software itself.
If I add the following to a projects .htaccess file, then it seems the web application works fine and no errors are generated. However I don't believe adding this to every project on my server is a suitable solution and I definitely thing there an issue somewhere, maybe bad ram?
php_flag opcache.enable Off
Firstly forgive me if my terminology isn't entirely accurate. I have only limited knowledge on this subject, but will best try to convey the problems we are having. My server administrator is trying to deploy php 5.5.9 on a live server. Originally the intention was to install php 5.4.x, but we opted for the latest version instead (a manual compile is required regardless due to the o/s)
The O/S is OpenSuse 12.1 and the server is a Plesk server (Plesk Version 11.0.9) with Apache 2.2.1. This particular o/s does not have the ability to update php automatically so everything has to be done manually. Since we didn't want to risk screwing up the server (currently running with php 5.3.8), we opted to install a second version of php alongside the current one. The instructions we followed are outlined here: http://kb.parallels.com/en/114753
After numerous failed attempts due to missing libraries during compilation, we were finally able to compile php 5.5.9 without error and then proceeded to run tests with 'make test'
Unfortunately, the test results came back with 32 failures and 20% of the total tests were skipped. A total of 13011 tests were done, 10410 of which were completed. The TEST SUMMARY can be downloaded from here: http://uploaded.net/file/v6ug55l8
Anyway, deciding we might aswell give it a try, we applied the changes as indicated in the first link above to the vhost.conf. However, it didn't work, and the vhost then returned Internal Server Errors for every page regardless of script or extension. The errors logs sadly do not indicate any errors, only a whole ton of internal server errors recorded by mod_security. We did notice a huge number of these in the error log: Warning: SuexecUserGroup directive requires SUEXEC wrapper. But, it doesn't seem to be related, as the same error goes back several weeks.
So, we're stuck without any idea what to do next. Our next attempt will be to try and compile a php 5.4.x instead, as perhaps something is bumping heads with 5.5.9...
Any and all advice will be appreciated. As per the opening statement, I'm not an expert here, so if you need any additional information about the machine and it's server, feel free to ask. Thankyou for your attention!
Problem solved. The vhost's CGI-BIN needed to be CHMOD 755 and not 775.
There is an IIS bug that causes problems with headers when using a CGI program, and setting a redirect to a page that returns a http 302 (Object Moved). The result is that IIS doesn't parse the headers, so if you're trying to set cookies, it's not going to work. See the KB Article
It says the solution is to start the EXE CGI with -nph (Non parsed Headers) - but I'm not really sure if it works in PHP. I tried adding it to my php file and manually building headers, but that didn't work for me..
Has anyone had this problem? Any good workarounds?
I'm not entirely sure how you're seeing this bug in the modern era.
First, Q17..., er, I mean, KB176113 was published in 1997. The examples list IIS 2.0 as the product affected, and the article itself claims only versions 3-5 are affected. Unless you're running your site on Windows 2000, you aren't using IIS5. Both the article and a bit of time in Google suggests that this problem is entirely fixed in IIS6 and later.
Second, the bug impacts only CGI scripts. If you are using PHP with IIS, then you are either using the ISAPI DLL (and if you are, I'm so sorry), or you're using FastCGI, which despite having three letters in common, is not actually CGI. Nobody has run PHP in CGI mode on IIS since...
You aren't using IIS5, are you?
Okay, if you aren't on IIS7, you might not be running in FastCGI mode. You should totally switch to FastCGI with modern PHP versions. Microsoft spent a lot of time and effort getting PHP and FastCGI playing nicely with IIS.
Third, setting cookies mid-redirect has been buggy in every browser on every platform at one time or another. Are you sure that the cookie header isn't actually being sent? Check your browser's development tools.
Prefixing the PHP file with nph-, not -nph - solved this issue for me.
e.g. nph-test.php