Using Syfony 2.2 in dev environment, trying to display a list view of the SonataAdminBundle.
I'm getting Error 325 / ERR_RESPONSE_HEADERS_TOO_BIG in Google Chrome. No problems in Safari and Firefox. This only happens in the dev environment and on every list view, edit views are ok.
Checked the headers via curl, seems fine:
curl -I http://project.local/app_dev.php/admin/project/site/user/list
HTTP/1.1 200 OK
Date: Sat, 23 Mar 2013 22:47:37 GMT
Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.1e DAV/2 PHP/5.3.22
X-Powered-By: PHP/5.3.22
Set-Cookie: PHPSESSID=hgfp4kdmjtl9neodli2d83e1i0; path=/
Cache-Control: no-cache
X-Debug-Token: 514e3109e09ae
Content-Type: text/html; charset=UTF-8
Disabled XDebug and APC, but no change there.
Thanks a lot for any pointers.
Check in your config_dev.yml for following lines and comment them.
#chrome:
#type: chromephp
#level: info
Why do you get this error?
It enables support of some sort of debugger for chrome like firephp in firefox...
http://www.chromephp.com/
Problem is that the response header is too big to print out the info because of a configuration setting on your server. If you increase the allowed size in your server config the problem will also disappear.
Related
I'm facing a problem trying to use php output compression , I've been searching for many hours and I still have no clues...
Lets see a simple script :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
if(function_exists('ob_gzhandler'))
{
ob_start('ob_gzhandler');
}
else {
ob_start();
}
echo $response;
ob_end_flush();
This is a method I've found all over the internet, and it used to work for me ... but not any more (and I've got no idea why) .
If i look at the http headers when I call this script :
Request :
Host: 192.168.51.191
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0
Response :
Connection: Keep-Alive
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:19:07 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.12
You can see that the response is NOT zipped (Firebird gives me a 0.06ko response), and the server sends the responses using chunked encoding.
I tried an alternate method to send zipped responses :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
$replyBody = gzencode($response, 9, FORCE_GZIP);
header("Content-Encoding: gzip");
echo $replyBody;
And the response headers are as follow (the request headers are always the same):
Response :
Connection: Keep-Alive
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:29:01 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
Transfer-Encoding: chunked
X-Powered-By: PHP/5.5.12
As you can see, this is basically the same behavior as in the first method.
Then if I try this :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
$replyBody = gzencode($response, 9, FORCE_GZIP);
echo $replyBody;
I receive something that looks like a zipped response (random characters), and the output size is 0.03ko .
Here a the corresponding response http headers :
Connection: Keep-Alive
Content-Length: 31
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:32:46 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
X-Powered-By: PHP/5.5.12
It lets me think that the zipping part is working correctly because the output size has been reduced (it is obviously not readable because the browser can't know that it is zipped content).
That's where I'm lost ...
If I understand it right, when I manually send zipped data (using gzencode) , If I set the header"Content-Encoding: gzip" , the webserver/php seems to UNZIP it before sending it to the browser ??? How is it possible ?
And Why is it sending it as "chunked" data instead of setting the Content-Length header ?
I tried to set the Content-Length manually in the response; it doesn't change anything (it won't appear in the response headers, I'll still have a "chunked" response.
I've seen somewhere that I have to write the "Content-Length" header before sending other data or header to avoid the "chunked" response, I tried it and still had the same results.
I thought it could be a problem with BOM characters at the beginning of my php test script, but it is saved in UTF-8 without BOM encoding so I don't think it 's the problem.
I have this problem on my dev computer (using wampserver) AND in the production environment (IIS), previously it was working on both servers.
I have this problem using several browsers, and I checked the response sizes I wrote previously with fiddler.
Does anyone see where the problem could be ?
Thanks in advance
I'd go through the following checklist if I were you.
1. Check zlib extension is installed or not.
ob_gzhandler needs the zlib extension to work. Without which it just silently falls back to default settings.
2. Verify that you don't have zlib.output_compression enabled in your php.ini.
As explained here, even though zlib.output_compression is preferred over ob_gzhandler(), you can not use both simultaneously. So your code becomes..
if (extension_loaded('zlib') && !ini_get('zlib.output_compression')){
ob_start('ob_gzhandler');
}
3. Check if headers have already been sent eg. something got output-ted before the
ob_start(ob_gzhandler) This will prevent the compressed output from being detected as such. eg. Having some character before <?php or an echo somewhere up in the code.
4. Make sure you aren't using all of the above in addition to the gzipping in apache(mod_deflate).
This will only cause the output to be double gzipped which most probably will confuse the browser.
Maybe it's the jetlag, but I'm failing to make PHP/HHVM give me the Content-Type header when I need it.
I've deployed the full stack (MySQL, HHVM, Nginx) on a Vagrant machine and I've managed to reproduce the issue on a test script:
<?php
$file='/usr/share/doc/iptables/html/NAT-HOWTO.html'; # random test file
header('Content-Length: ' . filesize($file));
echo(readfile($file));
?>
If you examine the headers with curl:
hostname:~ jsimpson$ curl -I http://vagrant/test.php
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 16 Sep 2014 22:09:25 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2592
Connection: keep-alive
X-Powered-By: HHVM/3.2.0
Content-Encoding: none;
We have a content length header. However if we hit the same URL from Chrome, and get the headers from the Dev tools:
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 16 Sep 2014 22:14:41 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: HHVM/3.2.0
Content-Encoding: gzip
No Content-Length header. I've also packet sniffed this to verify that the header isn't sent. I can switch to PHP FPM and it sends the header.
I reproduced the issue by hitting the server with:
curl -H 'Accept-Encoding: gzip,deflate' --compressed -v http://foo/bar
HHVM enables compression by default. Disabling that gave me the header back.
Everything was awesome after adding this to /etc/hhvm/server.ini
hhvm.server.gzip_compression_level = 0
I stumbled upon this issue/feature. Not running HHVM though. Pure nginx + PHP-FPM.
The thing is, if your PHP app calculates and sets Content-Lenght header field, and your nginx is configured to gzip content, it will just ditch this information and replace it by Chunked transfer encoding and GZIP headers.
So do not set GZIP to a very small buffers, default is 20 bytes which does quite the opposite (end result is larger then before GZIP compression).
I set it like this:
gzip_min_length 1024;
I could reduce my problem to the following script I put on my server:
<?php
session_start();
header('Content-type: text/plain', TRUE);
flush();
sleep(300);?>
When I connect to this script using:
GET /test.php HTTP/1.1
Host: localhost
I get the header back right away as expected:
HTTP/1.1 200 OK
Date: Sat, 03 Nov 2012 20:15:53 GMT
Server: Apache/2.2.22 (Fedora)
X-Powered-By: PHP/5.3.17
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie: PHPSESSID=m7bmvblakkil96rqjq7j8f0f42; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=UTF-8
If I then kill the connection and reconnect using:
GET /proxy/test.php HTTP/1.1
Host: localhost
Cookie: PHPSESSID=knkeaq2ao0cllpcci0rnassqj4
I don't get any header back anymore until I restart my webserver.
I would have expected to again retrieve the response header right away.
I have really no idea why I get this behavior. Maybe it's some kind of a bug? Or I'm misunderstanding some behavior.
It would be great if somebody could help me with this as I really don't have a clue what's going on.
Ps:
Im running Apache/2.2.22 with PHP 5.3.17 on fedora 17, but the server packages are out of the fedora 16 repos as I need zend debugger which does not work with the PHP coming with fedora 17.
Because your session is still open in the first request (for 300 seconds) you cannot start using it in the second. It will wait until the first session is closed and written to the file-system before it will attempt to read it for the second request. Because you cannot be sure the first request wants to modify the same session-variables which are already in use by the second request.
You can use session_write_close() before the sleep so that the session variables become available immediatly. But then you cannot change any session variables after that.
As pointed out in many other questions, turning display_errors to Off in php.ini makes the web server answer with status code 500 Internal server error instead of 200 OK when encountering a fatal error. I set up a simple test with an undefined function to explain the behaviour:
php.ini
display_errors = On
index.php
<?php test();
Gives:
Fatal error: Call to undefined function test()
in D:\xampp\htdocs\index.php on line 1
or just a blank page if i silence the function call like this:
<?php #test();
In both cases answer headers are as following:
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 20:08:22 GMT
Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
X-Powered-By: PHP/5.3.8
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
While changing php.ini to:
display_errors = Off
Causes:
HTTP/1.0 500 Internal Server Error
Date: Tue, 10 Jul 2012 20:10:35 GMT
Server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1
X-Powered-By: PHP/5.3.8
Content-Length: 0
Connection: close
Content-Type: text/html
Can anybody explain me the underlaying mechanism that makes the web server answer with 500 when display_errors is Off?
The reason is that with display_errors = On, you are essentially asking PHP to give you a decent HTTP response even when there are errors in your script. Think of it like an additional layer between your script and the response. It's no longer your script controlling the output, it's PHP.
When you turn this option on, you are in effect saying, "If there is an error, please still give me a valid HTTP response page (it may even include decent markup), since I will be looking at that instead of my logs."
With it set to Off, the HTTP response should be meaningless, and therefore a 500. With it On, a PHP error is anticipated, so the request on the whole is not 500, even though your script failed.
I have very specific problem running PHP as Apache 2.2 module. When running PHP as CGI, everything works OK, but slow. The output I get in this case is:
Good charset
But when runing PHP as Apache module on the same environment, I get the following output:
Wrong charset
The only difference is that I add following lines to appropriate VirtualHost in httpd.conf
SetEnv PHPRC "C:/PHP5/"
ScriptAlias /local-bin/ "C:/PHP5/"
AddHandler application/x-httpd-php5 php
Action application/x-httpd-php5 "/local-bin/php-cgi.exe"
<Directory "C:/PHP5/">
Order allow,deny
Allow from all
<Files "php-cgi.exe">
Allow from all
</Files>
</Directory>
The website uses 2 databases - one MySQL and one MSSQL. The text which is displayed incorrectly is retrieved from MSSQL database. There aren't any problems with text which is retrieved from MySQL database.
Any ideas how to run PHP as Apache module and get the same output as running PHP as CGI?
My setup is: Apache 2.2; PHP 5.2.17; mssql PHP extension 7.0; mbstring PHP extension 4.4.4
Headers in CGI mode, returned by curl -i
HTTP/1.1 200 OK
Date: Mon, 08 Aug 2011 11:56:15 GMT
Server: Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8o
X-Powered-By: PHP/5.2.13
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=3h4kpps0l02pecfgktonq7rjd6; path=/
Transfer-Encoding: chunked
Content-Type: text/html
Headers in PHP as a module mode:
HTTP/1.1 200 OK
Date: Mon, 08 Aug 2011 12:04:16 GMT
Server: Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8o PHP/5.2.13
X-Powered-By: PHP/5.2.13
Set-Cookie: PHPSESSID=hi9h3skbsjvpcr7usdlf36d2t7; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html
I don't know what was the exact problem, but everything seems to work OK now. I just downloaded fresh PHP package and configured it from scratch. What I didn't mention is that I use ZendServer Community Edition and it seems to cause the problems (by the way with same PHP 5.2.17 version). When I configure virtual host to use my fresh PHP installation - everything works OK, but when I use ZendServer built in PHP it causes problems.
Any ideas how to run PHP as Apache module and get the same output as running PHP as CGI?
Normally the output does not differ because of the module type but because of configuration. Just keep the same configuration across SAPI types and you're done.
The website uses 2 databases - one MySQL and one MSSQL. The text which is displayed incorrectly is retrieved from MSSQL database.
Looks like retrieving from MSSQL fails. Check if the data is properly encoded in the database. Check the client encoding settings. This should solve your issue.
You should indicate the encoding with the content type, e.g.
Content-Type: text/html; charset=utf-8
This fixes most issues.