Plesk Question posted in
The official documentation for Plesk Obsidian can be found here.

AMFPHP and Content-Encoding gzip on Apache – Plesk

I’m developing a Flash application with Flex and I use amfPHP (V2.2.1) for communicating with the PHP backend. Everything was fine since my web hoster changed from Confixx to Plesk and changed some settings on the web server, so after the change I’ve got always a “Net.Connection.Call.Failed HTTP: 200” error on the amfPHP service call.
After some research I’ve realised that the response header was now send with “Content-Encoding gzip” and turned this off in the .htaccess file with “RequestHeader unset Accept-Encoding”.
After that, all was fine again with my services and they work now as before.

My Question is. Is there another way to go around this issue? Is there a setting for amfPHP, so it can work with gzip compression, or another best practise for it?

Thanks in advance.

Add:
I found the amfPHP Plugin AmfphpGzip, but if I enable it, Flash throws an error “Error: Error #2030: End of file was encountered.”.
I don’t know why this happens. Could it be, that the data I want to get is to big (a parsed language.ini file from Joomla)?

Add 2:
(Made this part as an answer below)

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I think I found the solution now. In the AmfphpGzip plugin, there is a function which returns the length of a given string:

        protected function strlen($text){

    $length = 0;

    if (function_exists('mb_strlen')) {
        $length = mb_strlen($text);
    }
    else {
        // Do not count UTF-8 continuation bytes.
        $length = strlen(preg_replace("/[x80-xBF]/", '', $text));
    }

    return $length;
}

    The Flash throws the "Error: Error #2030: End of file was encountered." cause the Content-Length in the response header wasn't correct (the data from the ini file in the amf response was always truncated at the time when the error pops up). So I've changed that function to this:

    protected function strlen($text)
{
     return strlen($text);
}

    Now it works all well on my website hosting and on my local server. The Joomla language.ini files are all saved as UTF-8 (without BOM) and also all German special characters like ü, ß or ö are correct in the response. Also all other service calls work well, so i think, strlen is sufficient for this function to get the proper string length.


  2. 0

    It seems unlikely that an ini file containing only text is too much to handle for your server. To find out what is going wrong you’ll need to dig a bit deeper. See
    http://www.silexlabs.org/amfphp/documentation/troubleshooting-and-debugging-your-project/
    particularly “Getting information about PHP errors”.
    However, you might ask yourself if it’s worth the trouble. I don’t see huge value in gzipping an ini file. The bandwidth gains are probably quite modest.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search