I have an application (CakePHP 2.2) that worked fine up until lately, however all of a sudden it's started only delivering part of the page. The HTML for the page is truncated, however it doesn't always truncate at exactly the same place each time (although it's about the same place).
I've had someone else test this from another location & they also experienced the same problem.
The first time I had this problem I restarted the server & it appeared to resolve the problem, however it's happened again. This time I've tried restarting Apache, rather than the whole server & it does not appear to have resolved the problem.
I'm not sure what else to try, so any suggestions welcome.
Thanks in advance.
Update: I've also now tried disabling APC but the problem continued after this was disabled.
Another update: Having tried adding content above & below the point it was truncating, it would appear that it is truncating at a certain distance from the end of the file, as the approximate break point only moved when content is added after where it's breaking.
Yet another update...
OK, so I've done even more digging & there seems to be a problem with the calculation of the content length on my production server. Here's the output from my digging (Date headers stripped to save space)...
Server with Content-Length unset
If I unset the Content-Length header in the CakeResponse::_setContentLength(), the full page displays fine, & this is the header returned…
Connection close
Server Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_bwlimited/1.4
Transfer-Encoding chunked
X-Powered-By PHP/5.3.24
Server with Content-Length set
If I don't unset the Content-Length header then the page displayed is truncated, & the response headers are…
Connection close
Content-Length 2455
Content-Type text/html; charset=UTF-8
Server Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_bwlimited/1.4
X-Powered-By PHP/5.3.24
Local Machine with Standard Content-Length
I would think it's the header length calculation, apart from the fact that on my local machine, even without unsetting the Content-Length header, the full page displays, even though the Content-Length returned is the same as on the production server...
Connection Keep-Alive
Content-Length 2455
Content-Type text/html; charset=UTF-8
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8x
X-Powered-By PHP/5.3.15
From what I can gather,
the script must be die'ing and then stopping the HTML after the die code from displaying.
You need to look further into the code of CakePHP, and check that the logical functions are not ending unexpectedly and that there is no outstanding die function that could cause the HTML from loading.
Related
I'm using Apache 2.2 and PHP 7.0.1. I force chunked encoding with flush() like in this example:
<?php
header('HTTP/1.1 200 OK');
echo "hello";
flush();
echo "world";
die;
And I get unwanted characters at the beginning and end of the response:
HTTP/1.1 200 OK
Date: Fri, 09 Sep 2016 15:58:20 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/7.0.9
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
a
helloworld
0
The first one is the chunk size in hex (10 = A). I'm using Klein as PHP router and I have found that the problem comes up only when the HTTP status header is rewritten. I guess there is a problem with my Apache config, but I wasn't able to figure it out.
Edited: My problem had nothing to do with Apache but Nginx and chunked_transfer_encoding directive. Check the answer below.
This is how Transfer-Encoding: chunked works. The extra characters you're seeing are part of the encoding, rather than the body.
A client that understands the encoding will not include them in the result; a client that doesn't doesn't support HTTP/1.1, and should be considered bugged.
As #Joe pointed out before, that is the normal behavior when Chunked transfer enconding is enabled. My tests where not accurate because I was requesting Apache directly on the server. Actually, when I was experiencing the problem in Chrome I was querying a Nginx service as a proxy for Apache.
By running tcpdump I realized that Nginx was rechunking responses, but only when rewritting HTTP status header (header('HTTP/1.1 200 OK')) in PHP. The solution to sending Transfer-Encoding: chunked twice is to set chunked_transfer_encoding off in the location context of my Nginx .php handler.
I'm experiencing a strange issue on a WooCommerce installation my company has taken over. It's not us who built it and unfortunately it's pretty crappy built so I'm not so sure what's actually going on in there.
It suddenly started to "force" https connections, but as far as I know nothing has changed in nether the code nor from the admin. We are running Git on the server and nothing has changed in the working tree, and I searched the uploads folder for suspicious files with no results. It's very unlikely some kind of malware. The site is not set up with https/ssl so this does of course trigger a timeout.
I checked the database and both home_url and site_url are set to "http://...". The WooCommerce option "force ssl" is set to false. Also we are running the plugin "Better WP Security/iThemes Security" which also offers a "force ssl"-option but that one is set to false too.
I tried setting both the constants FORCE_SSL_ADMIN and FORCE_SSL_LOGIN to false in wp-config.php - still no luck. Also I tried using .htaccess rewrite rules but that didn't help either.
It seems to be connected with a request header; HTTPS: 1 (tested with $ curl -I -H"HTTPS: 1" http://...). When that one is set to 0 this does not happen. However Chrome seems to send it by default, which is not the case for other browsers. I tried clearing cookies/data etc. Problem appears in my colleague's browser as well (and she has never visited the site before). Hosting company says this is not related to server configuration.
Has anyone experienced this before, or know to what it could be related to?
Update:
Running curl -I -H"HTTPS: 1" http://www.example.com/wp-admin/ pretty much confirms this has something to do with Wordpress. The cookies are set by WPML which indicates Wordpress is initialized. Check the Location: header:
HTTP/1.1 302 Moved Temporarily
Server: Apache
X-Powered-By: PHP/5.6.11
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _icl_current_admin_language=sv; expires=Wed, 22-Jul-2015 16:06:25 GMT; Max-Age=7200; path=/wp-admin/
Set-Cookie: _icl_current_language=sv; expires=Thu, 23-Jul-2015 14:06:25 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=xxx; path=/
Location: https://www.example.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.example.com%2Fwp-admin%2F&reauth=1
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
Date: Wed, 22 Jul 2015 14:06:26 GMT
X-Varnish: nnn
Age: 0
Via: 1.1 varnish
Connection: keep-alive
http://develop.woothemes.com/woocommerce/2015/07/woocommerce-2-3-13-security-and-maintenance-release/
Updating Woocommerce to 2.3.13 fixed it for me
#Zertuk's solution is correct: upgrading to the latest WooCommerce should fix the issue because of the change that #Zertuk has linked.
To give more detail: Chrome has implemented the Upgrade Insecure Requests specification from the World Wide Web Consortium (W3C). Section 3.2.1 of that specification is The HTTPS HTTP Request Header Field which states
3.2.1. The HTTPS HTTP Request Header Field
The HTTPS HTTP request header field sends a signal to the server
expressing the client’s preference for an encrypted and authenticated
response, and that it can successfully handle the
upgrade-insecure-requests directive in order to make that preference
as seamless as possible to provide.
This preference is represented by the following ANBF:
"HTTPS:" *WSP "1" *WSP
WooCommerce's is_ssl() function before version 2.3.13 was incorrectly rewriting all the URLs in the response if the HTTPS: 1 header was set.
Upgrading to the latest version of WooCommerce (currently 2.3.13) fixes the bug.
I fixed this issue by turning off the Force SSL setting within WooCommerce Settings, and then explicitly setting these 3 WooCommerce pages to use SSL via the checkbox provided as part of this plugin (on the Edit Page screen).
The pages that needing SSL according to WooCommerce are:
1. Checkout
2. Checkout -> Pay
3. My Account
and also try,
<?php
if (is_ssl()) {
//action to take for page using SSL
}
?>
Returns true if the page is using SSL (checks if HTTPS or on Port 443).
Kirby is right.
I did a quick fix modifying the Wordpress core function is_ssl().
I return false at the beginning of the function because some of my websites do not have SSL.
It's not recommended modify the core of Wordpress because of the updates, but I can control that.
I am using a DocuSign API and have run into some issues.
When sending the data request to their server I am getting the following error:
SoapFault exception: [q0:InvalidSecurity] An error was discovered
processing the <Security> header ---> WSE065: Creation time of the
timestamp is in the future. This typically indicates lack of synchronization
between sender and receiver clocks. Make sure the clocks are synchronized
or use the timeToleranceInSeconds element in the microsoft.web.services3
configuration section to adjust tolerance for lack of clock synchronization.
I have looked all over their community forums and the only response I can find from their forum admin is this:
The message means that the client clock is wrong. The timezone might be set
incorrectly. If the SOAP request is timestamped too far in the future or in the
past, the server will reject it. We generally run into this error with mobile
apps since folks don't always have their devices set to sync to network time.
I checked my server time as well as my computer time to make sure everything is fine. My computer time is set to EST, and the server is set to CST. I have tried updated and synchronized my system clock on my computer as well as trying to adjust my timezone to CST to make sure they both match. I have also changed my computer time to GMT because that is what they say their server time is. I have also tried updating my server's clock since it seems to be the one that is a little bit off. (there seems to be like a 6 minute difference between my clock and the server clock).
I ran this command on the server:
sudo ntpdate ntp.ubuntu.com
Response:
27 Sep 08:51:41 ntpdate[18858]: step time server 91.189.94.4 offset -357.639332 sec
I also tried editing my grub configuration file on the server (/boot/grub/grub.conf). I tried adding different combinations of these params to the end of the kernel line:
clock=pit
acpi=off
noapic
As well as trying to update the hardware clock with this command:
hwclock=systohc
The soap headers are as follows:
This request was sent out at 10:41AM(my computer time [EST]), 9:47AM (my server time [CST]).
Request:
POST /api/3.0/api.asmx HTTP/1.1
Host: www.docusign.net
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.3.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.docusign.net/API/3.0/CreateEnvelope"
Content-Length: 116157
Response:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 1696
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 27 Sep 2012 14:41:13 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=7776000; includeSubDomains
If anyone has any thoughts as to what might be causing this error, or if anyone has any further advice on how to go about synchronizing my clocks, I would love to hear them.
Thanks in advance for your time and consideration.
I ended up contacting the company I am hosting my virtual server with and as it turns out it wasn't an issue with anything I have control over at all. It turned out that their hypervisor (virtual machine monitor - VMM) was having issues so when my server was synchronizing its time from it, my time was getting offset by about 7 minutes. Since the system clock of my server was being controlled by it, this also disallowed me from being able to set the time manually with this command:
date -s "27 SEP 2012 HH:MM:SS"
since the changes would just be superseded by the VMM.
I'd like to remove the following headers:
Connection: Keep-Alive
Server: Apache/2.2.13 (Win32)
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=66
I don't think this can be done properly in PHP, as these headers are set by Apache.
There is PHP 5.3's header_remove() but that can remove only headers set by PHP (If I understand correctly). You could also overwrite the undesired headers by sending them again with empty values, but the original values will be sent anyway.
The best thing would be to fix this at the root, in Apache's configuration. For example, the ServerTokens directive can change the "Server:" header.
Related: apache_response_headers()
You could turn your script into a non-parsed-header CGI. For that you have to rename your example.php script into nph-script.cgi, make it executable (+x) and add the shebang:
#!/usr/bin/php-cgi
<?php
This requires you to send ALL http headers yourself however, including the HTTP/1.0 200 OK status line. (see rfc2616 php.ini config)
Oh, and actually I have no clue if this still works for current Apache versions.
Using PHP (or any other server site language) and sending the header Connection: close. This will cause Apache to omit the Keep-Alive header, since the connection is no longer keepalive. e.g.
header('Connection: close');
Not sure if it works same on all types of servers, suggestions welcome.
Read More here
I'm using PHP to redirect a page back to the previous page with the following:
header("Location: {$_SERVER['HTTP_REFERER']}");
This set of pages will only be used by internal users, so I'm not terribly concerned about the fact that the referer will not always be available.
The problem I'm running in to is that if the referer looks like http://subdomain.domain.com/test.php?id=13, the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13. Notice the additional .domain.com/ in the url.
I've tested by hardcoding the value, and it causes the problem as well. phpMyAdmin seems to suffer the same issue, but only on this particular server.
If this is not an SO question, please move accordingly.
EDIT: per #yaggo
test.php contains only header("Location: http://subdomain.domain.com/test2.php");
curl --head --referer 'http://subdomain.domain.com/' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Server: nginx/0.7.64
Date: Fri, 02 Apr 2010 17:21:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.2.12-pl0-gentoo
Location: .domain.com/test2.php
I've recreated both your programs on my server
once with
header("Location: http://subdomain.domain.com/some/place");
and once with
header("Location: {$_SERVER['HTTP_REFERER']}");
and both give the corret result
curl --head --referer 'http://subdomain.domain.com/some/place' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Date: Fri, 02 Apr 2010 17:48:54 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.2
Location: http://subdomain.domain.com/some/place
Connection: close
Content-Type: text/html
I'm using a different version of PHP and a different webserver, so there's two things to investigate.
It seems that your nginx configuration is causing the problems.
Its totally possible that nginx is modifying the response headers. This is not by default - you could have a configuration that is aimed for it to behave as a reverse proxy etc.
Have you tried testing the redirect on a nginx with its default configuration?
[...] the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13.
Can you isolate the problem a little bit more? Is that url exactly what is returned by PHP or is it how browser (Chrome?) sees it?
Can you check the actual headers e.g. with curl:
$ curl --head --referer 'http://your-referer' 'http://your-page/'
header("Location: ".$_SERVER['HTTP_REFERER']);
Edited:
Check you .htaccess settings or if no solution found u can use preg_replace to remove that last ".domain.com"
but it looks that is a not a php error.
OR use javascript to get the referer address...
then use window.location.href = url; to redirect ...