AMFPHP et Content-Encoding gzip sur Apache

Je développe une application Flash avec Flex et j'utilise amfPHP (V2.2.1) pour communiquer avec le backend PHP. Tout allait bien puisque mon hébergeur est passé de Confixx à Plesk et a changé certains paramètres sur le serveur web, donc après le changement, j'ai toujours une erreur "Net.Connection.Call.Failed HTTP: 200" sur l'appel de service amfPHP. Après quelques recherches, j'ai réalisé que l'en-tête de réponse était maintenant envoyé avec "Content-Encoding gzip" et l'ai désactivé dans le fichier .htaccess avec "RequestHeader unset Accept-Encoding". Après cela, tout allait bien avec mes services et ils fonctionnent maintenant comme avant.AMFPHP et Content-Encoding gzip sur Apache

Ma question est. Existe-t-il un autre moyen de contourner ce problème? Existe-t-il un paramètre pour amfPHP, de sorte qu'il peut fonctionner avec la compression gzip, ou une autre meilleure pratique pour cela?

Merci d'avance.

Ajouter:
J'ai trouvé le amfphp Plugin AmfphpGzip, mais si je l'activer, Flash renvoie une erreur « Erreur: Erreur # 2030:. Fin du fichier a été rencontré ». Je ne sais pas pourquoi cela arrive. Se pourrait-il que les données que je veux obtenir soient trop grandes (un fichier language.ini analysé par Joomla)?

Ajouter 2:
(fait cette partie comme une réponse ci-dessous)

Source

2014-09-17 Bio

Il semble peu probable qu'un fichier ini contenant que du texte est trop à gérer pour votre serveur. Pour découvrir ce qui ne va pas, vous devrez creuser un peu plus loin. Voir http://www.silexlabs.org/amfphp/documentation/troubleshooting-and-debugging-your-project/ en particulier "Obtenir des informations sur les erreurs PHP". Cependant, vous pourriez vous demander si cela en vaut la peine. Je ne vois pas de valeur énorme dans gzipping un fichier ini. Les gains de bande passante sont probablement assez modestes.

Source

2014-09-18 07:12:46

J'ai supprimé tous les commentaires précédents, parce que c'était un problème complètement différent et j'ai obtenu la solution maintenant. Je vais l'ajouter à ma question ci-dessus. Mais oui, ça n'en vaut pas la peine, mais j'ai dû faire avec, parce que le composant Joomla que je développe devrait fonctionner immédiatement, sans avoir besoin d'éditer le fichier .htaccess par l'utilisateur et ce n'est pas vraiment une solution désactiver l'encodage de transfert complètement sur le serveur. En tout cas - merci pour votre réponse et votre aide! – Bio

Je pense avoir trouvé la solution maintenant. Dans le plugin AmfphpGzip, il y a une fonction qui renvoie la longueur d'une chaîne donnée:

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; 
}

Le flash lance le « Erreur: Erreur # 2030: Fin du fichier a été rencontré. » parce que la longueur de contenu dans l'en-tête de réponse n'était pas correcte (les données du fichier ini dans la réponse amf étaient toujours tronquées au moment où l'erreur apparaissait). Donc j'ai changé cette fonction à ceci:

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

Maintenant, tout fonctionne bien sur mon hébergement de site Web et sur mon serveur local. Les fichiers Joomla language.ini sont tous sauvegardés en UTF-8 (sans BOM) et tous les caractères spéciaux allemands comme ü, ß ou ö sont corrects dans la réponse. Aussi, tous les autres appels de service fonctionnent bien, donc je pense que strlen est suffisant pour que cette fonction obtienne la bonne longueur de chaîne.

Source

2014-09-18 23:41:15 Bio

AMFPHP et Content-Encoding gzip sur Apache

Répondre

Questions connexes