Hi Fede,

The ping problem looks like a problem on this site. You can disable the ping in Global settings -> Plugins install and find the 'Ping B2evolution' plugin.
I can't help you with the second problem without more information. The site is fine in my setup. Nice site by the way.

Good luck

Afwas, thanks for your answer. But as we don't want to loose the pinging funcionality, what we done is to put $accepted_encoding = ''; in _xmlrpc.inc.php, line about 1270, just before $op= 'POST ' . $uri. " HTTP/1.0\r\n" .

We hope this doesn't affect something else, now it seems to be working.

Thanks again.

Hi Fede,

It looked to be a charset problem. Your solution also points into that direction.
What is the value of $accepted_encoding right before you reset it?
To avoid troubles you can temporarily store the original value and restore the variable after pinging. I'm wondering if i'd call this a bug or not. ;)

Good luck

Afwas

The value was 'gzip', don't know why. And don't know either if there is a bug or any apache parameter in our server or what...

More likely a wrong setting in the B2evoluion.net server. That gzip is unexpected by me also. I will notify those who maintain our servers. Thanks for reporting the info.

Good luck

Don't know if this will help, but Apache-based web servers can be configured to compress files (typically HTML, JS, CSS and TXT files only) ... IF the user agent accepts compression (typically gzip format).

Apache 1.0 uses mod_gzip to achieve this and Apache 2.0 uses mod_deflate

More info: http://www.sitepoint.com/article/web-output-mod_gzip-apache/

Fede - what appears to be happening is that by pinging with the variable set to 'gzip', your server was sending a compressed file (that for some reason, couldn't be uncompressed at the other end). By changing it from 'gzip' to '' (none), you're no longer sending a compressed file when pinging (and don't get the decompression error).

The gzip compression stuff is basically used to save bandwidth.

Hope this helps.

-stk

Hi stk,

Thanks for helping to solve this riddle.
But my question is this: Is it a B2evolution (blog) setting (looks like it since it's a variable that is recognized - I haven't investigated this) and if it is, why is the B2evolution server not responding?
It's more like the B2evolution server sends gzipped html and the blog server can't decompress it. That would make it something that should be able to set and even something that should be checked before it's tried (bug)

I'll see what I can find regarding the variable in the code.

--F

In /inc/_ext/xmlrpc/_xmlrpc.inc.php around line 1000 this is the header comment of a function:

		/**
		* Enables/disables http compression of xmlrpc request.
		* Take care when sending compressed requests: servers might not support them
		* (and automatic fallback to uncompressed requests is not yet implemented)
		* @param string $compmethod either 'gzip', 'deflate' or ''
		* @access public
		*/

So manually set this to '' (empty) is a valid solution to the problem. I don't seem to be able to find what actually sets the variable to 'gzip' in the first place.

Same file line 786:

		/**
		* List of http compression methods accepted by the client for responses.
		* NB: PHP supports deflate, gzip compressions out of the box if compiled w. zlib
		*
		* NNB: you can set it to any non-empty array for HTTP11 and HTTPS, since
		* in those cases it will be up to CURL to decide the compression methods
		* it supports. You might check for the presence of 'zlib' in the output of
		* curl_version() to determine wheter compression is supported or not
		*/
		var $accepted_compression = array();

Maybe the user's server is running Apache 2 and using mod_deflate, instead of mod_gzip and the accept method is "gzip" when the actual compression sent is "deflate"? (Just a wild guess)

I don't know a lot about mod_deflate, as our server is running Apache 1.x.

I'd try "deflate", posting and see if they get a similar error on ping. If not, then that's the problem. If yes, then just turn off the xmlprc compression accepts and go "un-compressed".

Not sure how it's set originally ... sounds like "gzip" is the default? (While you can ACCEPT 'gzip', you don't have to ... so if it comes uncompressed, it'd still be readable ... if the server sent a compressed file that was either (a) corrupt or (b) not quite the format expected - would you get the message).

Dunno ... just guessing.

Yes, I saw that function, setRequestCompression($compmethod), but it's not called anywhere! So I supposed it's not used.

The same with the variable $compmethod, the comment arround line 1020 says * @param string $compmethod either 'gzip', 'deflate' or '', but it doesn't get a value anywhere.

stk, our server is apache 2 (www.lahaine.org/phpinfo.php), but where can I see if it's using mod_deflate?

Anyway, I'll try forcing mod_deflate

Afwas wrote:

So manually set this to '' (empty) is a valid solution to the problem. I don't seem to be able to find what actually sets the variable to 'gzip' in the first place.

I think this sums it up, at least with the knowledge we have at this moment.

I agree, because using $accepted_encoding = 'Accept-Encoding: deflate\r\n'; arround line 1270 gives the same error

This code is external from [url=http://phpxmlrpc.sourceforge.net]XML-RPC for PHP[/url]. I'll upgrade to the latest version soon and before B2evolution v3 arrives.

Fede - Here's a site that shows if your server is sending compressed data (it reads gzip, but AFAIK it checks both mod_deflate and mod_gzip).

It also shows if the user-agent is sending an gzip accept header.

http://www.whatsmyip.org/mod_gzip_test/

Hope it helps.