During setting up for our production environment we encounter a wierd error, when trying to curl through our server, it returns a plain text representation of the response including the http headers this request is over ssl.
Date: Fri, 19 Jun 2015 02:15:00 GMT
Content-Type: text/html
Content-Length: 70619
Last-Modified: Thu, 18 Jun 2015 05:30:30 GMT
Connection: keep-alive
ETag: "55825776-113db"
Accept-Ranges: bytes
<!DOCTYPE html>
<html lang="en-us">
<head>
and so on...
Any ideas on how to fix this?
Set CURLOPT_HEADER to false in your curl_setopt like so:
curl_setopt($ch, CURLOPT_HEADER, false);
CURLOPT_HEADER - TRUE to include the header in the output. (ref)
Fixed this bug, it turns out I was setting CURLOPT_HEADER instead of CURLOPT_HTTPHEADER
Related
My PHP code returns a JSON string and sets to the response header Content-Type: application/json.
On localhost it works fine, it just returns the JSON string I passed. But, request to the remote server, on my browser network/header, the content type is application/x-httpd-php5. And the content, before the json string, it prints the texts in the std-output and that header string:
X-Powered-By: PHP/7.2.8
Cache-Control: private, must-revalidate
Date: Wed, 08 Aug 2018 02:49:36 GMT
Content-Type: application/json
pragma: no-cache
expires: -1
X-Debug-Token: 187f4e
after that I get the json string I sent.
The PHP version of my PC and the hosting is PHP 7.2. I use Apache. The hosting supposed too. But, from the browser response header, I see Server: nginx.
From the server into Mime types, I got application/json -> json. I uploaded a .json file, I got Content-Type: application/json. I set to my .htaccess file
AddDefaultCharset utf-8
AddType 'application/json; charset=UTF-8' .json
but still nothing changes.
I don't know why on my localhost I got Content-Type: application/json but on the hosting I got application/x-httpd-php5.
Here is the raw Response:
HTTP/2.0 200 OK
server: nginx
date: Wed, 08 Aug 2018 03:31:45 GMT
content-type: application/x-httpd-php5
cache-control: max-age=0
expires: Wed, 08 Aug 2018 03:31:44 GMT
X-Firefox-Spdy: h2
So I've got a server to server application. The PHP script on server 1, domain 1 sets a custom header in the page (Authorization: Bearer 123456789). The script on server 2, domain 2 uses get_headers() to read the headers.
It all works fine when the files are served natively. But when the script on server 1 is included in a Joomla module get_headers() doesn't retrieve the custom header.
In both cases, developer tools shows the custom header but also some different headers than returned by get_headers().
The code below uses JFactory to set the headers if Joomla is loaded but it is the same result using header(). Joomla just isn't passing the custom header.
I don't get it. Anyone have any idea what is going on here? Its not a SEF or htaccess issue.
<?php
// Server 1
if(!class_exists("JFactory")){ // no Joomla
header('Authorization: Bearer 123456789');
} else { // Joomla framework loaded
$app = JFactory::getApplication();
$app->setHeader('Authorization: ', 'Bearer 123456789');
$app->sendHeaders();
}
The code on server 2:
<?php
// Server 2
$headers = get_headers("http://server1.com/");
foreach($headers as $header) {
echo $header ."<br/>";
}
Output from get_headers() when served natively:
HTTP/1.1 200 OK
Date: Thu, 19 Jan 2017 12:44:35 GMT
Server: Apache
Authorization: Bearer 123456789
Content-Length: 0
Connection: close
Content-Type: text/html
Output from get_headers() when served by Joomla:
HTTP/1.1 200 OK
Date: Thu, 19 Jan 2017 12:45:49 GMT
Server: Apache
Set-Cookie: 3c460b3da9ecb202e794816b4144c6ff=ja7mn4b4njov98lsv76kk8pvu2; path=/; HttpOnly
Vary: Accept-Encoding
Content-Length: 1264
Connection: close
Content-Type: text/html
Native headers displayed by developer tools:
Authorization: Bearer 123456789
Date: Thu, 19 Jan 2017 13:07:32 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Content-Length: 0
Content-Type: text/html
200 OK
Joomla headers displayed by developer tools:
Pragma: no-cache
Date: Thu, 19 Jan 2017 12:19:24 GMT
Last-Modified: Thu, 19 Jan 2017 12:19:25 GMT
Server: Apache
Authorization: : Bearer 123456789
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Content-Length: 76888
Expires: Wed, 17 Aug 2005 00:00:00 GMT
Remove double dot from setheader call :
$app = JFactory::getApplication();
$app->setHeader('Authorization', 'Bearer 123456789');
$app->sendHeaders();
Thanks for the suggestion Yoleth. I tested this and got the same result.
However I have found the problem. The Joomla site setting the header is using a component called Site Lock. This is similar to putting the site off line but has some nice features for developers.
Basically Site Lock was preventing the page being served and just returning the headers from the lock page (as it should). I don't know why I didn't see it earlier. Sometimes just can't see the forest for the trees!
My browser shows page with incorrect encoding. I have figured out that the server sends headers
HTTP/1.1 200 OK
Date: Thu, 02 Jan 2014 18:21:11 GMT
Server: Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8k PHP/5.2.12
X-Powered-By: PHP/5.2.12
Content-Length: 4
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=windows-1251
but php script doesn't contain encoding set command. I even added exit on the script top and browser still getting Content-Type: text/html; charset=windows-1251. How so?
First look at default_charset in php.ini. Leave it empty if you do not want a Content-Type header.
In PHP one always can do a header('Content-Type', 'text/html; charset=UTF-8');.
Apache also has a config for Content-Type, but the error probably lies at the PHP side.
I'm trying to parse an xml feed using PHP:
http://trustbox.trustpilot.com/r/travelnation.co.uk.xml
Visiting this, it looks perfectly OK, but when I try
<?php
$file = file_get_contents("http://trustbox.trustpilot.com/r/netamity.com.xml");
print_r($file);
?>
I get
‹•SÁŽÓ0=/ÿ`ŒÄmœ- 븊àèJV«••L«ŽmÙN²ý{Æi·M
...
How is it getting garbled? Using simplexml it wont parse it (unsurprisingly). I've tried setting headers UTF-8 headers but I think the issue is in the get_file_contents. Any ideas?
The content looks "weird" simply because the encoding is compressed (see the HTTP header Content-Encoding: gzip).
HTTP/1.1 200 OK
x-amz-id-2: 8wYarFnod0jtLJ3U8ZDN38102fjtG+EbwJjy0tY4YTZncrz9auEcQbzt1vyiSEhq
x-amz-request-id: A60F1E6CA5437776
Date: Sun, 24 Feb 2013 18:00:45 GMT
Content-Encoding: gzip
Last-Modified: Sun, 24 Feb 2013 05:19:11 GMT
ETag: "64eaa6f87768aeb3ae6741ba06318cb6"
Accept-Ranges: bytes
Content-Type: application/xhtml+xml
Content-Length: 52366
Server: AmazonS3
I guess what you need is to know how to read a file over HTTP; you could try this one on SO.
I have spotted a "weird" php CURL behavior that is sending me nuts. Basically what I am doing is making a digest authenticated call with curl. Here's an extract of my code:
curl_setopt($this->c, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($this->c, CURLOPT_USERPWD, $username . ":" . $password);
It works fine and the server actually comes back with a "YES, YOU PROVIDED THE RIGHT CREDENTIALS" kind of message. Only trouble is, the raw http response is a bit odd as it includes, as a matter of fact, 2 responses instead of one. Here's what curl_exec($this->c) spits out:
HTTP/1.0 401 Unauthorized
Date: Tue, 23 Oct 2012 08:41:18 GMT
Server: Apache/2.2.20 (Ubuntu)
X-Powered-By: PHP/5.3.6-13ubuntu3.9
WWW-Authenticate: Digest realm="dynamikrest-testing",qop="auth",nonce="5086582e95104",opaque="4b24e95490812b28b3bf139f9fbc9a66"
Vary: Accept-Encoding
Content-Length: 9
Connection: close
Content-Type: text/html
HTTP/1.1 200 OK
Date: Tue, 23 Oct 2012 08:41:18 GMT
Server: Apache/2.2.20 (Ubuntu)
X-Powered-By: PHP/5.3.6-13ubuntu3.9
Vary: Accept-Encoding
Content-Length: 9
Connection: close
Content-Type: text/html
"success"
I don't get why it includes the first response from the server (the one in which it states it requires authentication).
Can anyone throw some light on the issue? How do I avoid the responses' cumulation?
Cheers
It looks like curl has the same behavior if you use the -I option for headers:
curl -I --digest -u root:somepassword http://localhost/digest-test/
returns:
HTTP/1.1 401 Authorization Required
Date: Fri, 31 May 2013 13:48:35 GMT
Server: Apache/2.2.22 (Ubuntu)
WWW-Authenticate: Digest realm="Test Page", nonce="9RUL3wPeBAA=52ef6531dcdd1de61f239ed6dd234a3288d81701", algorithm=MD5, domain="/digest-test/ http://localhost", qop="auth"
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
HTTP/1.1 200 OK
Date: Fri, 31 May 2013 13:48:35 GMT
Server: Apache/2.2.22 (Ubuntu)
Authentication-Info: rspauth="4f5f8237e9760f777255f6618c21df4c", cnonce="MTQ3NDk1", nc=00000001, qop=auth
Vary: Accept-Encoding
Content-Type: text/html;charset=UTF-8
X-Pad: avoid browser bug
To only get the second header you could try this (not very optimal solution):
<?php
$ch = curl_init();
// set url
curl_setopt($ch, CURLOPT_URL, "http://localhost/digest-test/");
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, "root:test");
// first authentication with a head request
curl_setopt($ch, CURLOPT_NOBODY, 1);
curl_exec($ch);
// the get the real output
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_HTTPGET, 1);
$output = curl_exec($ch);
echo $output;
I hit the same problem, and I think it was caused by PHP being compiled against an ancient version of libcurl (7.11.0 in my case, which is now nearly 10 years old). On a different machine with a more recent version of libcurl (7.29.0) the same code was fine, and my problems ended after getting my host to recompile their PHP to use the latest they had available (7.30.0).
This fix was suggested by a thread on the curl-library mailing list from 2008, where a user discovered the problem affected version 7.10.6 but not 7.12.1. I've searched the libcurl changelog around 7.12.0 and failed to find any clear entry about fixing this problem, though it might be covered by "general HTTP authentication improvements". Still, I'm now pretty confident that an old libcurl is the problem.
You can check which version of libcurl is used by your PHP from the 'cURL Information' entry in the output of phpinfo();