I recently enabled SSL on my Prestashop site, but my 2 cronjobs stopped working with error:
Status: 301 Moved Permanently
X-Powered-By: PHP/5.6.25
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Location: https://www.xxxxxx.it
The cron command is: php /home/xxxxx/public_html/path/command.php
I cannot use wget or curl.
Any ideas?
Check the cron logs at the path
/var/log/cron
and it will give you an idea of whats happening
Related
I have two hosting environments, one is running PHP 7.4 with Apache, and the other one is running PHP 8.1 with Nginx both on Azure.
I run this PHP script on both:
<?php ini_set("display_errors", 1); header('Status: 301 Moved Permanently', true, 301); ?>
When I run this code on host 1, I get what I expect; the headers are output as 301:
D:\home\site\wwwroot>curl -is test.php
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 25 Nov 2022 08:46:09 GMT
Server: Microsoft-IIS/10.0
X-Powered-By: PHP/7.4.30
X-Powered-By: ASP.NET
Running the same script om the Nginx environement under PHP 8.1 I get:
root:/home# curl -is localhost:8080
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Fri, 25 Nov 2022 08:45:33 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/8.1.9
<br />
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /home/site/wwwroot/index.php:1) in <b>/home/site/wwwroot/index.php</b> on line <b>1</b><br />
As you can see the header 301 could not be sent because the 200 header was already sent.
There is absolutely nothing before the first <?php-tag.
I have tried lots of things with the Nginx config, but no result. Is this something that is inside PHP.INI?
What is causing the header 200 to be sent before any line of my PHP script?
Solution: output_buffering is apparently disabled by default, you can turn it on in the INI of PHP, like so:
Create a folder inside /home/site called ini
Add a file there with the extention .ini, like site.ini
Add this line and save:
output_buffering = on
Go to your azure portal to the webapp and inside Configuration add an application setting with name = PHP_INI_SCAN_DIR and value = /usr/local/etc/php/conf:/home/site/ini
Then save the application setting witch will restart your app.
It seems that by default, PHP-CLI now runs solely in quiet mode, instead of requiring the user to pass -q or --no-header.
For example, if phptest.php is the following:
<?php header("Location: http://www.something.com"); ?>
We can request it using cURL and an Apache server, with the following result:
$ curl -I "http://localhost/phptest.php"
HTTP/1.1 302 Found
Date: Tue, 20 Mar 2018 16:47:48 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.24
Location: http://www.something.com
Content-Type: text/html
But if we request through the PHP-CLI, we get nothing:
$ php /var/www/phptest.php
My question, then, is how can I get the PHP-CLI to return headers as well? If it's not possible, what alternatives exist (short of cURLing or wgeting it)?
Use php-cgi instead of php:
$ php-cgi /var/www/phptest.php
Status: 302 Moved Temporarily
X-Powered-By: PHP/5.6.32
Location: http://www.something.com
Content-type: text/html; charset=UTF-8
I'm trying to see if the following code in htaccess in Cakephp2 is working to block the SemrushBot.
SetEnvIfNoCase User-Agent "SemrushBot" Access
I want to test on my local server by sending a SemrushBot to my site with the following crl command.
curl -k --head -H 'User-agent: SemrushBot' https://192.xxx.xx/mysamplesite.com
After using the above command, I get the following result. It seems like it has been requested but the problem is I'm not getting the error log.
The error log should contain "File does not exist" & "client denied by server configuration" because the SemrushBot was attempting to access my site.
I believe that the error log should show in Cakephp2's tmp/logs/. Some tips and examples would be great. I would love to hear from you.
Date: Mon, 05 Jun 2017 09:44:33 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Location: https://192.xxx.xx/mysamplesite.com
Connection: close
Content-Type: text/html; charset=iso-8859-1
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;
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.