415 Types de support non pris en charge - Encodage non pris en charge

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit un code d'état HTTP 415 Unsupported Media Type avec code d'erreur protocol.http.UnsupportedEncoding en réponse aux appels d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant: 

HTTP/1.1 415 Unsupported Media Type

En outre, un message d'erreur semblable à celui présenté ci-dessous peut s'afficher: 

{
   "fault":{
      "faultstring":"Unsupported Encoding \"UTF-8\"",
      "detail":{
         "errorcode":"protocol.http.UnsupportedEncoding"
      }
   }
}

Causes possibles

Cette erreur se produit si la valeur de l'en-tête Content-Encoding spécifiée dans la requête HTTP envoyée par le client à Apigee ou la réponse HTTP envoyée par le serveur backend à Apigee ne contient pas codage pris en charge par Apigee, conformément à la spécification <ph type="x-smartling-placeholder"></ph> RFC 7231, section 6.5.13: 415 Unsupported Media Type.

<ph type="x-smartling-placeholder">

Les causes possibles de cette erreur sont les suivantes:

Cause Description Instructions de dépannage applicables
Encodage non accepté utilisé dans la requête L'en-tête de requête Content-Encoding contient un encodage non compatible. par Apigee Edge. Utilisateurs Edge de cloud public et privé
Encodage non accepté utilisé dans la réponse L'en-tête de réponse du serveur backend Content-Encoding contient un encodage qui n'est pas pris en charge par Apigee Edge. Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Pour diagnostiquer l'erreur, vous pouvez utiliser l'une des méthodes suivantes:

Surveillance des API

<ph type="x-smartling-placeholder">

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

  1. <ph type="x-smartling-placeholder"></ph> Connectez-vous à votre compte Apigee Edge.

  2. Passez à l'organisation dans laquelle vous souhaitez examiner le problème:

    menu déroulant de l&#39;organisation de l&#39;interface utilisateur
  3. Accédez à Analyser > Surveillance des API > Examiner.
  4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
  5. Assurez-vous que le filtre Proxy est défini sur Tous.
  6. Représentez le code d'erreur par rapport à l'heure.

  7. Sélectionnez une cellule avec le code d'erreur protocol.http.UnsupportedEncoding comme indiqué ci-dessous:

    cellule de code d&#39;erreur sélectionnée

  8. Les informations sur le code d'erreur protocol.http.UnsupportedEncoding s'affichent comme suit:

  9. Cliquez sur Afficher les journaux et développez l'une des requêtes qui échouent avec 415. pour afficher plus d'informations:

  10. Dans la fenêtre Journaux, notez les détails suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Fault Source (Source de l'erreur) : indique que l'erreur est renvoyée par apigee. ou target.
    • Code d'erreur:il doit correspondre à protocol.http.UnsupportedEncoding.
  11. Si la source de la défaillance est apigee, cela indique que la requête contient un encodage non compatible dans l'en-tête Content-Encoding.
  12. Si la source d'erreur est target, cela indique que le serveur backend L'en-tête Content-Encoding de la réponse contenait un encodage non compatible.

Outil Trace

<ph type="x-smartling-placeholder">

Pour diagnostiquer l'erreur à l'aide de l'outil Trace:

  1. Activez le session Trace, puis effectuez l'une des opérations suivantes: <ph type="x-smartling-placeholder">
      </ph>
    • Attendez que l'erreur 415 Unsupported Media Type se produise.
    • Si vous pouvez reproduire le problème, effectuez l'appel d'API pour reproduire 415 Unsupported Media Type erreur.

  2. Assurez-vous que l'option Show all FlowInfos (Afficher toutes les informations FlowInfos) est activée:

    afficher le volet d&#39;options, afficher tous les infos du flux
  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.

  5. L'erreur s'affiche généralement dans un flux après la demande Request sent to target serveur comme indiqué ci-dessous:

  6. Notez la valeur de l'erreur à partir de la trace.

    L'exemple de trace ci-dessus indique l'erreur sous la forme Unsupported Encoding "utf-8". Depuis l'erreur est signalée par Apigee après l'envoi de la requête au serveur backend, cela indique que le serveur backend a envoyé l'en-tête de réponse Content-Encoding avec la valeur de "utf-8", qui n'est pas encodage compatible avec Apigee.

  7. Accédez à la phase AX (Données analytiques enregistrées) dans la trace, puis cliquez dessus.

  8. Faites défiler la page jusqu'à la section Error / Response Headers (En-têtes d'erreur/de réponse) dans Phase Details (Détails de la phase). panneau et déterminer les valeurs de X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué ci-dessous:

  9. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source par protocol.http.UnsupportedEncoding et target, ce qui indique que est générée, car la valeur d'encodage non prise en charge de "utf-8" a été transmise par le dans l'en-tête de réponse Content-Encoding.

    En-têtes de réponse Valeur
    X-Apigee-fault-code protocol.http.UnsupportedEncoding
    X-Apigee-fault-source target

  10. Vérifiez si vous utilisez <ph type="x-smartling-placeholder"></ph> le chaînage de proxy ; c'est-à-dire si le serveur/point de terminaison cible appelle une autre dans Apigee.

    1. Pour le déterminer, revenez à la phase Demande envoyée au serveur cible. Cliquez sur Show Curl (Afficher le mouvement curl).

    2. La fenêtre Curl for Request Sent to Target Server (Curl pour la requête envoyée au serveur cible) qui s'ouvre vous permet de déterminer l'alias d'hôte du serveur cible.
    3. Si l'alias hôte du serveur cible pointe vers un alias d'hôte virtuel, il s'agit d'un proxy et le chaînage. Dans ce cas, vous devez répéter toutes les étapes ci-dessus pour le proxy enchaîné jusqu'à vous déterminez ce qui est à l'origine de l'erreur 415 Unsupported Media Type.
    4. Si l'alias d'hôte du serveur cible pointe vers votre serveur backend, cela indique que votre serveur backend transmet l'encodage non pris en charge à Apigee.

Journaux d'accès Nginix

<ph type="x-smartling-placeholder">

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX:

  1. Si vous êtes un utilisateur du Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés sur les erreurs HTTP 415.

  2. Vérifiez les journaux d'accès NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    <ph type="x-smartling-placeholder">
  3. Recherchez les erreurs 415 pendant une période spécifique (si le problème s'est produit). ou si des requêtes échouent toujours avec 415.

  4. Si vous trouvez des erreurs 415 avec la correspondance X-Apigee-fault-code la valeur de protocol.http.UnsupportedEncoding, puis déterminez la valeur de X-Apigee-fault-source.

    Exemple d'erreur 415 dans le journal d'accès NGINX:

    L'exemple d'entrée ci-dessus du journal d'accès NGINX présente les valeurs suivantes pour X- Apigee-fault-code et X-Apigee-fault-source:

    En-têtes de réponse Valeur
    X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
    X-Apigee-fault-source MP

    X-Apigee-fault-source peut également avoir laX-Apigee-fault-source valeurX-Apigee-fault-source .

Cause: encodage non accepté dans la requête

Diagnostic

  1. Déterminez le code d'erreur et la source d'erreur pour l'erreur observée à l'aide de l'API. Journaux d'accès Monitoring ou NGINX comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si le code d'erreur est protocol.http.UnsupportedEncoding et que la valeur Fault Source a la valeur apigee ou MP, cela indique que le L'en-tête de la requête envoyée par l'application cliente contient un encodage non compatible Content-Encoding
  3. Vous pouvez déterminer la valeur de l'encodage non compatible transmis dans la requête HTTP. à l'aide de l'une des méthodes suivantes:

    Message d'erreur

    Utilisation du message d'erreur: <ph type="x-smartling-placeholder">
      </ph>

    1. Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, consultez à faultstring. faultstring contient la valeur de l'élément incompatible le codage final.

      Exemple de message d'erreur:

      "faultstring":"Unsupported Encoding \"UTF-8\""

    2. Dans le message d'erreur ci-dessus, notez que la valeur de l'encodage non pris en charge est “UTF-8” comme indiqué dans faultstring.

      Étant donné que “UTF-8” n'est pas un encodage pris en charge dans Apigee Edge, cette requête échoue avec l'erreur 415 Unsupported Media Type avec le code d'erreur suivant: protocol.http.UnsupportedEncoding

    Demande réelle

    Avec la requête réelle: <ph type="x-smartling-placeholder">
      </ph>
    1. Si vous n'avez pas accès à la requête réelle envoyée par l'application cliente, accédez à Résolution.
    2. Si vous avez accès à la requête proprement dite effectuée par l'application cliente, exécutez la procédez comme suit: <ph type="x-smartling-placeholder">
        </ph>
      1. Déterminez la valeur transmise à l'en-tête de requête Content-Encoding.
      2. Si la valeur transmise à l'en-tête de requête Content-Encoding n'est pas 1 parmi les valeurs listées dans la section Encodage compatible, il s'agit la cause de cette erreur.

        Exemple de requête:

        curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: UTF-8" -X POST -d @request_payload.gz

        L'exemple de requête ci-dessus envoie la valeur "UTF-8" à l'en-tête Content- Encoding, qui n'est pas un Encodage pris en charge dans Apigee Edge. Par conséquent, cette requête échoue avec l'erreur 415 Unsupported Media Type avec le code d'erreur suivant: protocol.http.UnsupportedEncoding

Solution

  1. Consultez la liste des encodages compatibles avec Apigee dans Encodage compatible.
  2. Assurez-vous que l'application cliente envoie toujours les éléments suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Seul l'encodage compatible correspond à la valeur de l'en-tête Content-Encoding dans la demande
    • La charge utile de la requête au format compatible avec Apigee Edge et correspond au format spécifié dans l'en-tête Content-Encoding

  3. Dans l'exemple ci-dessus, la charge utile de la requête comporte une extension gz, qui indique que le contenu doit être gzip. Vous pouvez résoudre le problème en envoyant l'en-tête de la requête en tant que Content-Encoding: gzip et la charge utile de la requête au format gzip:

    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz

Cause: encodage non accepté dans la réponse

Diagnostic

  1. Déterminez le code d'erreur et la source d'erreur pour l'erreur observée à l'aide de l'API. les journaux d'accès Monitoring, Trace ou NGINX comme expliqué dans l'article Étapes de diagnostic courantes.
  2. Si la source de la défaillance a la valeur target, cela indique que le envoyée par le serveur backend contient un encodage non pris en charge dans le Content-Encoding.
  3. Vous pouvez déterminer la valeur de l'encodage non pris en charge transmis dans la réponse HTTP à partir de serveur backend à l'aide de l'une des méthodes suivantes:

    Message d'erreur

    Utilisation du message d'erreur: <ph type="x-smartling-placeholder">
      </ph>

    1. Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, reportez-vous à faultstring. faultstring contient la valeur de encodage non pris en charge.

      Exemple de message d'erreur:

      "faultstring":"Unsupported Encoding \"UTF-8\""

    2. Dans le message d'erreur ci-dessus, notez que la valeur de l'encodage non pris en charge est “UTF-8” comme indiqué dans faultstring.

      Comme “UTF-8” n'est pas un encodage pris en charge dans Apigee Edge, cette La requête échoue avec l'erreur 415 Unsupported Media Type avec le code d'erreur suivant: protocol.http.UnsupportedEncoding

    Outil Trace

    Utiliser Trace: <ph type="x-smartling-placeholder">
      </ph>
    1. Si vous ne disposez pas de la trace de la requête ayant échoué, accédez à Résolution.
    2. Si vous avez capturé une trace pour l'échec, vous pouvez déterminer la couche non prise en charge encodage transmis par le serveur backend dans la réponse Content-Encoding comme expliqué dans l'outil Trace.

Solution

  1. Consultez la liste des encodages compatibles avec Apigee dans Encodage compatible
  2. Assurez-vous que le serveur backend envoie toujours les éléments suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Seul l'encodage compatible est la valeur du paramètre En-tête Content-Encoding dans la requête
    • La charge utile de la réponse dans le format pris en charge vers Apigee Edge et correspond au format spécifié dans l'en-tête Content-Encoding

Encodage compatible

Le tableau suivant répertorie les formats d'encodage compatibles avec Apigee Edge:

En-tête Encodage Description
Content-Encoding gzip Format Unix gzip
deflate Ce format utilise la structure zlib avec un algorithme de compression de décompression.

Spécification

Apigee répond avec la réponse d'erreur 415 Unsupported Media Type conformément aux spécification RFC suivante:

Spécification
<ph type="x-smartling-placeholder"></ph> RFC 7231, section 6.5.13: 415 Unsupported Media Type

Points clés à noter

Veuillez noter les points suivants :

  • Si l'erreur 415 est renvoyée par Apigee en raison d'un encodage non compatible transmis l'en-tête Content-Encoding dans la requête API, puis: <ph type="x-smartling-placeholder">
      </ph>
    • Vous ne pourrez pas capturer la trace pour ces requêtes.

    • Vous ne pourrez pas modifier le format ni le contenu de la réponse d'erreur envoyée par Apigee Edge à l'aide de règles telles que RaiseFault et assignMessage.

    En effet, cette erreur se produit à un stade précoce du processeur de messages, avant toute peut être exécutée.

  • Si l'erreur 415 est renvoyée par Apigee en raison d'un encodage non compatible transmis dans l'en-tête de réponse de votre serveur backend, le problème doit être corrigé dans le serveur backend pour éviter cette erreur. Veuillez contacter votre équipe backend si nécessaire pour résoudre ce problème.

Si vous avez toujours besoin de l'aide de l'assistance Apigee Edge, consultez Obligation de recueillir des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si vous avez toujours besoin de l'aide de l'assistance Apigee, rassemblez les éléments suivants de diagnostic, puis contactez l'assistance Apigee Edge:

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:

  • Nom de l'organisation
  • Nom de l'environnement
  • Nom du proxy d'API
  • Exécutez la commande curl utilisée pour reproduire l'erreur 415.
  • Fichier de suivi des requêtes API

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

  • Message d'erreur complet observé pour les requêtes en échec
  • Nom de l'environnement
  • Groupe de proxys d'API
  • Fichier de suivi des requêtes API

  • Journaux d'accès NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Où:ORG, ENV et PORT# sont remplacés par les valeurs réelles.

  • Journaux système du processeur de messages /opt/apigee/var/log/edge-message- processor/logs/system.log