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.
Related
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 created simple react app as described in https://reactjs.org/docs/add-react-to-a-new-app.html and now want to make AJAX calls to the webserver (with PHP). To make it working with development server at localhost:3000 I am trying to set up proxy in package.json
"proxy": {
"/abc": {
"target": "http://web.local/app/path/public/abc",
"secure": false,
"changeOrigin": true,
"logLevel": "debug"
}
}
Unfortunately app answers with default index.html content. How to make proxy working when requesting /abc path?
Is there any way to test and debug proxy? When I try to open http://localhost:3000/abc I can see
[HPM] POST /abc/abc -> http://web.local/app/path/public/abc
in console. But there is no messages when I'm loading app and request is sent from the app. (I tried fetch and axios calls.)
When I build app and run it on web server, all works fine.
EDIT:
Response Headers for the axios ajax call:
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 143
Vary: Accept-Encoding
Date: Wed, 03 Jan 2018 17:44:02 GMT
Connection: keep-alive
For fetch:
HTTP/1.1 301 Moved Permanently
X-Powered-By: Express
Content-Type: text/html; charset=UTF-8
Content-Length: 165
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Location: /abc/
Vary: Accept-Encoding
Date: Wed, 03 Jan 2018 17:58:37 GMT
Connection: keep-alive
And
HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
ETag: W/"649-W8GnY7MkgPFg6/GXObpRHPnVDeU"
Vary: Accept-Encoding
Content-Encoding: gzip
Date: Wed, 03 Jan 2018 17:58:37 GMT
Connection: keep-alive
Transfer-Encoding: chunked
I resolved issue. My php files were located in public/ dir of the app (to have them included in build). And it is accessible from development web server as static content. Now proxy checks if file exists in public/ and delivers it if possible. And if there is no such file, then rules are applied and it tries to fetch data from specified URL.
So I moved all php related files to other location and needed data are delivered from web server through proxy as inteded just with
"proxy": "http://web.local/app/path/static"
in package.json.
Also I had to add separate command to copy content of this dir to build/ and add it to build process.
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
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.