L'API FEDEX Ship renvoie des informations compressées sur certaines erreurs

Question

J'ai implémenté l'API Fedex à l'aide de l'API Check Rates et je peux créer des étiquettes à l'aide de l'API Ship. Les deux ont bien fonctionné dans le bac à sable, j'ai donc fait certifier mon label et je l'ai mis en ligne. L'API doit renvoyer JSON. Parfois, en live et sandbox, les appels d'API utilisant cURL renvoient des réponses non JSON. Vous n'aurez jamais de problème à obtenir une bonne réponse json en utilisant OAuth ou en vérifiant les appels d'API. Cependant, l'API Ship peut renvoyer un bon json, mais elle peut également renvoyer des réponses compressées.

Ceci est ma demande curl.

fonction fedexRequest($endpoint, $post, $header = null) {
    //$ch = curl_init('https://apis-sandbox.fedex.com/' . $endpoint);
    $ch = curl_init('https://apis.fedex.com/' . $endpoint);
    curl_setopt_array($ch, [
        CURLOPT_SSL_VERIFYPEER => vrai, CURLOPT_SSL_VERIFYHOST =>
        CURLOPT_RETURNTRANSFER => vrai, CURLOPT_FOLLOWLOCATION =>
        CURLOPT_CONNECTTIMEOUT => 5, CURLOPT_POSTFIELDS =>
    ]);
    if ($header) curl_setopt($ch, CURLOPT_HTTPPHEADER, $header);
    return curl_exec($ch);
}
J'ai obtenu une réponse json et compressée en utilisant ce code. $post est la charge utile json que je leur envoie. Alerte spoil! L'erreur concerne généralement les détails de quelque chose dans la charge utile. La première erreur consiste à définir PackagingType = FEDEX_PAK pour les articles pesant plus de 20 livres. Une autre approche consiste à utiliser CM au lieu de IN pour les unités de taille. 
Mes appels au support des services Web Fedex ont des difficultés à diagnostiquer les réponses d'erreur non-json. La réponse ressemble au code du navigateur : diamant noir vs blanc ? et des espaces, des lettres et des chiffres aléatoires. 
La première personne à me dire exactement ce qu'elle a vu en regardant les appels de l'API de mon compte, à me dire la cause et la solution de l'erreur, et même à voir mes bonnes balises en temps réel après avoir implémenté leur configuration. Les réponses sont admirées. J'espère que je recevrai un rappel direct de sa part. J'ai également passé quelques appels d'assistance aujourd'hui, mais personne n'a pu fournir la même aide au diagnostic. Le dernier indique que vous recevez une réponse compressée, alors gérez-la. Ils ont dit que leur responsable avait déclaré que c'était mon code qui provoquait la réponse compressée. 
C'est déroutant, et lorsque je suis dans le bac à sable, je vois des erreurs dans les bonnes réponses json et je crée des méthodes pour les analyser de manière appropriée pour l'utilisateur final. J'ai également vu ces réponses de code. Je pensais que c'était juste un bug connu de leur bac à sable, mais apparemment, certains de leurs bugs ont été corrigés. 
J'ai donc quelques questions.
La compression est-elle provoquée par ma requête cURL ? 
Si je définis CURLOPT_ENCODING dans la requête, ces réponses seront-elles traitées de manière plus appropriée ? 
Si je reçois une réponse compressée, gzread ou ZipArchive sont-ils le meilleur moyen de la décompresser et d'obtenir le code d'erreur réel ? Et si c'était là ? 
            

Answer 1

Il semble que les requêtes cURL adressées à Fedex puissent renvoyer des réponses compressées et non compressées. L'ajout de CURLOPT_ENCODING => "" au tableau cURL setopt décompresse automatiquement les réponses gzip.