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.
Related
I'm all of a sudden having a hard time downloading excel spreadsheets from our webserver.
We use apache2.2.22 and php 5.4.45-0+deb7u7.
The files are corrupt after download.
I've verified the spreadsheet files are OK. (I'm able to open them w/o problem if I don't download them via the browser then try to look at them.)
Here's the response header:
Cache-Control no-store, no-cache, must-reval…te, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Length 22
Content-Type text/html
Date Mon, 29 Jan 2018 17:56:52 GMT
Expires Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive timeout=3, max=100
Pragma no-cache
Server Apache/2.2.22 (Debian)
Vary Accept-Encoding
X-Powered-By PHP/5.4.45-0+deb7u7
I'm just totally stumped here.
I've also been trying to add a mime-type like this:
case "xlsx":
header("Content-type: application/vnd.ms-excel-xml");
header("Content-Disposition: attachment; filename=\"".$path_parts["basename"]."\""); // use 'attachment' to force a download
break;
Nothing seems to be working. (but it used to work flawlessly.)
Any help or ideas come much appreciated. Thank you.
Situation
I have implemented a modified version of the kirby Auth plugin on a client website, it basically works this way
User accounts are simple kirby content files with the title serving as the login and a password field containing a bcrypt encrypted version of the users password
On the website, visitors can click on "Customer Area", which goes to a template managed by the modified auth plugin (which redirects to the "login" form).
The website is multilingual. So the accounts file will look like content/extranet/login/login.fr.txt or as an example content/extranet/bastian/bastian.fr.txt, this is what the modified Auth plugin is looking for, it finds the file and reads it, checks the password, and the logins the users.
This system requires account pages title to be the same as their URL, and to always be invisible pages
User is logged in and can only see in the « secure » template the files present in his folder
This all works good here on my local MAMP server as you can see in the screenshots, but on the production server http://www.driving-evolution.com, this doesn’t work, and i don’t know why, i have looked in a lot of places and i don’t understand what is going on. (it doesn’t work on the staging server either)
On the production server, wether you enter a good or a bad login, the form doesn’t show any error message, and doesn’t log the user in either. At first i thought this is maybe because of my bcrypt install, but it is not, as i disabled it (and used plain passwords instead) and it still didn’t work.
The issue seems NOT to be from the plugin here but from a difference between my live PHP stack and local php stack (my guess is on the php session handling).
Remote PHP is 5.3.3
Here is a sample output of CURL on both installations :
WORKING (Local)
curl -d "username=test&password=test" -i devo.loc/fr/login
HTTP/1.1 302 Found
Date: Tue, 27 May 2014 12:59:49 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 PHP/5.5.3
X-Powered-By: PHP/5.5.3
Set-Cookie: PHPSESSID=9249a942248a2382d8eb10090bf5d825; 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
Set-Cookie: authFrontend=mc06csp25; expires=Wed, 28-May-2014 12:59:49 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=b38ec0b342356c2c38778e4a6925f085; path=/
Set-Cookie: authFrontend=8qyyn; expires=Wed, 28-May-2014 12:59:49 GMT; Max-Age=86400; path=/
Location: http://devo.loc/fr/extranet
X-UA-Compatible: IE=edge
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html; charset=utf-8
FAILING (Remote)
curl -d "username=test&password=test" -i www.driving-evolution.com/fr/login
HTTP/1.1 200 OK
Date: Tue, 27 May 2014 13:01:32 GMT
Server: Apache
X-Powered-By: PHP/5.3.3
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=6j9o1i4djetojtbg444i51efm7; path=/
Vary: Accept-Encoding
X-UA-Compatible: IE=edge
Connection: Keep-Alive, close
Transfer-Encoding: chunked
Content-Type: text/html
USEFUL LINKS
REMOTE PHPVER : http://www.driving-evolution.com/phpver.php
SCREENSHOTS when it works on local
Hope someone will be able to help me on this ! Ask for any further info and i will give it.
Turns out it WAS a problem with the CMS, file caching was turned on and not ignoring the "login", "logout", and "extranet" files (all related to customer area), had to add :
c::set('cache.ignore', array('api', 'sitemap', 'extranet', 'account', 'login', 'logout'));
to my kirby config (api and sitemap are unrelated).
This fixes the problem as the login form was cached and thus not hitting anything on the server. Now form is not cached.
I have created two files, one on my wamp server (localhost), and one on my ovh.com private space. Both files contains only this content :
echo $search = file_get_contents('https://prod.api.pvp.net/api/lol/euw/v1.3/game/by-summoner/19319907/recent?api_key=6fa73a35-6477-412d-97a6-b6739cb6cf1b');
On my server, there is some wrong characters, like â, þ or ¬, etc ...
How it can happends, and how can I resolve this ?
Edit: It's not about files ! It's about servers, cause files are exactly the same !
You can check the good one here : http://www.dietadom.fr/test.php, and the bad one here : http://82.124.50.144/test.php
headers from requests to both those scripts:
Working:
curl -I http://www.dietadom.fr/test.php
HTTP/1.1 200 OK
Set-Cookie: clusterBAK=R1564861669; path=/; expires=Wed, 19-Mar-2014 16:38:43 GMT
Date: Wed, 19 Mar 2014 15:19:31 GMT
Content-Type: text/html
Connection: keep-alive
Set-Cookie: cluster=R1649376954; path=/; expires=Wed, 19-Mar-2014 16:32:22 GMT
Server: Apache
X-Powered-By: PHP/5.4.24
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Vary: Accept-Encoding
Not Working:
curl -I http://82.124.50.144/test.php
HTTP/1.1 200 OK
Date: Wed, 19 Mar 2014 15:19:48 GMT
Server: Apache/2.4.4 (Win64) OpenSSL/1.0.1d PHP/5.4.12
X-Powered-By: PHP/5.4.12
Content-Type: text/plain; charset: UTF-8
Most likely the default character encoding header provided by your two servers is different. You can fix this by changing the server configurations to make sure they both have the default. Or you can modify your script to over-ride this, adding a content encoding header will make this consistent.
If you modify your PHP file for UTF-8 plain test content the line would be
header('Content-type: text/plain; charset=UTF-8');
Your source URL is responding with:
Content-Type: application/json; charset=UTF-8
retrieved using
curl -I https://prod.api.pvp.net/api/lol/euw/v1.3/game/by-summoner/19319907/recent?api_key=6fa73a35-6477-412d-97a6-b6739cb6cf1b
hence how I know it's UTF-8 encoded.
EDIT
Having checked against your server I can see the header for an error page of:
curl -I http://82.124.50.144/404.html
HTTP/1.1 403 Forbidden
Date: Wed, 19 Mar 2014 17:24:17 GMT
Server: Apache/2.4.4 (Win64) OpenSSL/1.0.1d PHP/5.4.12
Content-Type: text/html; charset=iso-8859-1
The last line showing me the default charecter encoding is iso-8859-1, which means that the utf-8 data from your source is being transmitted with the wrong encoding. Adding the correct header line to your script should fix the issue.
You could change your apache server configuration by adding AddDefaultCharset UTF-8 as well.
I'm sure that your issue is with character encoding, so you should look into that.
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.
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.