415 Nicht unterstützter Medientyp – nicht unterstützte Codierung

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 415 Unsupported Media Type mit Fehlercode protocol.http.UnsupportedEncoding als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 415 Unsupported Media Type

Außerdem kann eine Fehlermeldung wie die folgende angezeigt werden:

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

Mögliche Ursachen

Dieser Fehler tritt auf, wenn der Wert des Headers Content-Encoding entweder in die HTTP-Anfrage, die vom Client an Apigee gesendet wird, oder die HTTP-Antwort vom Back-End-Server an Apigee enthält nicht die Von Apigee unterstützte Codierung (gemäß der Spezifikation) <ph type="x-smartling-placeholder"></ph> RFC 7231, Abschnitt 6.5.13: 415 Nicht unterstützter Medientyp.

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

Mögliche Ursachen für diesen Fehler:

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
In der Anfrage wird nicht unterstützte Codierung verwendet Der Anfrageheader „Content-Encoding“ enthält eine nicht unterstützte Codierung von Apigee Edge. Edge-Nutzer von öffentlichen und privaten Clouds
Nicht unterstützte Codierung in der Antwort Der Antwortheader Content-Encoding des Back-End-Servers enthält eine Codierung, die wird von Apigee Edge nicht unterstützt. Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

Zur Diagnose des Fehlers können Sie eine der folgenden Methoden verwenden:

API-Monitoring

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

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

  1. <ph type="x-smartling-placeholder"></ph> Melden Sie sich in Ihrem Apigee Edge-Konto an.
  2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten:

    UI-Drop-down-Menü
  3. Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
  4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
  5. Achten Sie darauf, dass der Filter Proxy auf Alle gesetzt ist.
  6. Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
  7. Wählen Sie eine Zelle mit dem Fehlercode protocol.http.UnsupportedEncoding aus, wie unten gezeigt:

    Fehlercodezelle ausgewählt
  8. Informationen über den Fehlercode protocol.http.UnsupportedEncoding werden wie folgt angezeigt:

  9. Klicken Sie auf Logs ansehen und maximieren Sie eine der Anfragen, bei denen 415 fehlschlägt. Fehler beim Anzeigen weiterer Informationen:

  10. Im Fenster Logs werden die folgenden Details angezeigt: <ph type="x-smartling-placeholder">
      </ph>
    • Fehlerquelle: Zeigt an, dass der Fehler von apigee zurückgegeben wird. oder target.
    • Fehlercode:Muss mit protocol.http.UnsupportedEncoding übereinstimmen.
  11. Wenn die Fehlerquelle apigee ist, bedeutet dies, dass die Anfrage Der Content-Encoding-Header enthielt eine nicht unterstützte Codierung.
  12. Wenn die Fehlerquelle target ist, bedeutet das, dass der Back-End-Server Die Antwort enthielt im Content-Encoding-Header eine nicht unterstützte Codierung.

Trace-Tool

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

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  1. Aktivieren Sie die Funktion . Trace-Sitzung und entweder <ph type="x-smartling-placeholder">
      </ph>
    • Warten Sie, bis der Fehler 415 Unsupported Media Type auftritt, oder
    • Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus, um 415 Unsupported Media Type Fehler.
  2. Achten Sie darauf, dass Alle FlowInfos anzeigen aktiviert ist:

    Ansichtsoptionen-Bereich, alle Flussinfos anzeigen
  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
  4. Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.
  5. Sie finden den Fehler normalerweise in einem Ablauf nach der Anfrage an das Ziel gesendet server-Phase wie unten gezeigt:

  6. Notieren Sie sich den Wert des Fehlers aus dem Trace.

    Im obigen Beispiel-Trace wird der Fehler als Unsupported Encoding "utf-8" angezeigt. Seit wird der Fehler von Apigee ausgegeben, nachdem die Anfrage an den Backend-Server gesendet wurde, dass der Backend-Server den Antwortheader Content-Encoding mit dem Wert von "utf-8". Dies ist kein unterstützte Codierung in Apigee.

  7. Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.
  8. Scrollen Sie nach unten zum Abschnitt Fehler-/Antwort-Header in Phase Details. und bestimmen, die Werte für X-Apigee-fault-code und X-Apigee-fault-code, wie unten gezeigt:

  9. Sie sehen die Werte X-Apigee-fault-code und X-Apigee-fault-code als protocol.http.UnsupportedEncoding und target. Dies bedeutet, dass dies wird verursacht, da der nicht unterstützte Codierungswert "utf-8" vom Back-End-Server im Antwortheader Content-Encoding.

    Antwortheader Wert
    X-Apigee-fault-code protocol.http.UnsupportedEncoding
    X-Apigee-fault-source target

  10. Überprüfen Sie, ob Sie <ph type="x-smartling-placeholder"></ph> Proxy-Verkettung wenn der Zielserver/Zielendpunkt einen anderen Proxy in Apigee.
    1. Um dies zu ermitteln, gehen Sie zurück zur Phase Anfrage an Zielserver gesendet. Klicken Sie auf Show Curl (Curl anzeigen).

    2. Das Fenster Curl für die an den Zielserver gesendete Anfrage wird geöffnet, in dem Sie den Host-Alias des Zielservers zu ermitteln.
    3. Wenn der Hostalias des Zielservers auf einen Alias des virtuellen Hosts verweist, ist es ein Proxy Verkettungen. In diesem Fall müssen Sie alle oben genannten Schritte für den verketteten Proxy wiederholen, bis können Sie ermitteln, wo der 415 Unsupported Media Type-Fehler tatsächlich liegt.
    4. Wenn der Hostalias des Zielservers auf Ihren Backend-Server verweist, bedeutet dies, dass übergibt Ihr Backend-Server die nicht unterstützte Codierung an Apigee.

Nginix-Zugriffslogs

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

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

  1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs ermitteln, enthält die wichtigsten Informationen zu HTTP-415-Fehlern.
  2. Prüfen Sie die NGINX-Zugriffslogs:

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

    <ph type="x-smartling-placeholder">
  3. Suche nach 415 Fehlern innerhalb eines bestimmten Zeitraums (wenn das Problem aufgetreten ist) in der Vergangenheit) oder Anfragen gibt, die immer noch mit 415 fehlschlagen.
  4. Wenn Sie 415-Fehler mit dem X-Apigee-fault-code finden Wert von protocol.http.UnsupportedEncoding und dann den Wert bestimmen der X-Apigee-fault-source..

    Beispiel 415 Fehler aus NGINX-Zugriffsprotokoll:

    Der obige Beispieleintrag aus dem NGINX-Zugriffsprotokoll enthält die folgenden Werte für X- Apigee-Fehlercode und X-Apigee-Fehler-Quelle:

    Antwortheader Wert
    X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
    X-Apigee-fault-source MP

    X-Apigee-fault-source könnte auch denX-Apigee-fault-source Wert X-Apigee-fault-source haben.

Ursache: Nicht unterstützte Codierung in Anfrage

Diagnose

  1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den mit der API beobachteten Fehler. Monitoring- oder NGINX-Zugriffs-Logs, wie unter Häufige Diagnoseschritte.
  2. Wenn der Fehlercode protocol.http.UnsupportedEncoding und der Fehlercode Quelle den Wert apigee oder MP hat, bedeutet dies, dass der Die von der Clientanwendung gesendete Anfrage enthält im Anfrageheader eine nicht unterstützte Codierung Content-Encoding
  3. Sie können den Wert einer nicht unterstützten Codierung ermitteln, die als Teil der HTTP-Anfrage übergeben wird. mithilfe einer der folgenden Methoden:

    Fehlermeldung

    Über die Fehlermeldung: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn Sie Zugriff auf die vollständige Fehlermeldung von Apigee Edge haben, verweisen Sie auf zu faultstring. faultstring enthält den Wert der nicht unterstützten Endcodierung.

      Beispielfehlermeldung:

      "faultstring":"Unsupported Encoding \"UTF-8\""
    2. In der obigen Fehlermeldung sehen Sie, dass der Wert der nicht unterstützten Codierung “UTF-8” wie in der faultstring zu sehen.

      Da “UTF-8” in Apigee Edge keine unterstützte Codierung ist, wird diese Anfrage schlägt mit dem Fehler 415 Unsupported Media Type mit dem Fehlercode fehl: protocol.http.UnsupportedEncoding

    Tatsächliche Anfrage

    Mit der eigentlichen Anfrage: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage der Clientanwendung haben, gehen Sie zu Lösung.
    2. Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie den folgenden Schritten: <ph type="x-smartling-placeholder">
        </ph>
      1. Ermitteln Sie den Wert, der an den Anfrageheader Content-Encoding. übergeben wird
      2. Wenn der an den Anfrageheader Content-Encoding übergebene Wert kein Wert ist der unter Unterstützte Codierung aufgeführten Werte, ist das die Ursache des Fehlers.

        Beispielanfrage:

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

        In der Beispielanfrage oben wird der Wert "UTF-8" an den Content- Encoding-Header gesendet. Dieser ist kein Unterstützte Codierung in Apigee Edge. Daher schlägt diese Anfrage mit dem Fehler 415 Unsupported Media Type und dem Fehlercode fehl: protocol.http.UnsupportedEncoding.

Auflösung

  1. Eine Liste der von Apigee unterstützten Codierungen finden Sie unter Unterstützte Codierung.
  2. Die Clientanwendung muss immer Folgendes senden: <ph type="x-smartling-placeholder">
      </ph>
    • Nur die unterstützte Codierung als Wert für den Content-Encoding-Header in die Anfrage
    • Die Nutzlast der Anfrage im unterstützten Format an Apigee Edge und entspricht dem Format angegeben im Content-Encoding-Header
  3. Im obigen Beispiel hat die Nutzlast der Anfrage die Erweiterung gz, die angibt, dass der Inhalt gzip sein muss. Sie können das Problem beheben, indem Sie den Anfrageheader senden als Content-Encoding: gzip und die Nutzlast der Anfrage im Format gzip:

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

Ursache: Nicht unterstützte Codierung als Antwort

Diagnose

  1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den mit der API beobachteten Fehler. Monitoring-, Trace-Tool- oder NGINX-Zugriffslogs wie unter Häufige Diagnoseschritte.
  2. Wenn die Fehlerquelle den Wert target hat, bedeutet dies, dass der Antwort, die vom Back-End-Server gesendet wurde, enthält eine nicht unterstützte Codierung in der Content-Encoding-Header.
  3. Sie können den Wert einer nicht unterstützten Codierung ermitteln, der als Teil der HTTP-Antwort von den Back-End-Server mit einer der folgenden Methoden:

    Fehlermeldung

    Über die Fehlermeldung: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn Sie Zugriff auf die vollständige Fehlermeldung von Apigee Edge haben, dann Weitere Informationen finden Sie im faultstring. faultstring enthält den Wert des eine nicht unterstützte Codierung.

      Beispiel für eine Fehlermeldung:

      "faultstring":"Unsupported Encoding \"UTF-8\""
    2. In der obigen Fehlermeldung sehen Sie, dass der Wert der nicht unterstützten Codierung “UTF-8” wie in der faultstring zu sehen.

      Da “UTF-8” in Apigee Edge keine unterstützte Codierung ist, gilt Folgendes: Die Anfrage schlägt aufgrund des Fehlers 415 Unsupported Media Type mit dem Fehlercode fehl: protocol.http.UnsupportedEncoding

    Trace-Tool

    Trace verwenden: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn Ihnen kein Trace für die fehlgeschlagene Anfrage vorliegt, gehen Sie zu Lösung.
    2. Wenn Sie einen Trace für den Fehler erfasst haben, können Sie die nicht unterstützte Codierung, die vom Back-End-Server als Teil der Content-Encoding-Antwort übergeben wird wie unter Trace-Tool erläutert.

Auflösung

  1. Eine Liste der von Apigee unterstützten Codierungen finden Sie unter Unterstützte Codierung
  2. Achten Sie darauf, dass der Back-End-Server immer Folgendes sendet: <ph type="x-smartling-placeholder">
      </ph>
    • Nur die unterstützte Codierung als Wert für den Content-Encoding-Header in der Anfrage
    • Die Antwortnutzlast im unterstützten Format für Apigee Edge und entspricht dem Format angegeben im Content-Encoding-Header

Unterstützte Codierung

In der folgenden Tabelle ist das von Apigee Edge unterstützte Codierungsformat aufgeführt:

Header Codierung Beschreibung
Content-Encoding gzip Das Unix-gzip-Format
deflate Dieses Format verwendet die zlib-Struktur mit dem deflate-Komprimierungsalgorithmus.

Spezifikation

Apigee antwortet mit der Fehlerantwort 415 Unsupported Media Type gemäß folgende RFC-Spezifikation:

Spezifikation
<ph type="x-smartling-placeholder"></ph> RFC 7231, Abschnitt 6.5.13: 415 Nicht unterstützter Medientyp

Wichtige Punkte

Wichtige Hinweise:

  • Wenn der Fehler 415 von Apigee aufgrund einer nicht unterstützten Codierung zurückgegeben wird den Content-Encoding-Header als Teil der API-Anfrage, dann: <ph type="x-smartling-placeholder">
      </ph>
    • Sie können den Trace für solche Anfragen nicht erfassen.
    • Sie können das Format oder den Inhalt der Fehlerantwort, die von Apigee Edge mit den Richtlinien wie RaiseFault, AssignMessage.

    Das liegt daran, dass dieser Fehler in einer frühen Phase im Message Processor auftritt, bevor ausgeführt werden kann.

  • Wenn der Fehler 415 von Apigee aufgrund einer nicht unterstützten Codierung zurückgegeben wird im Antwortheader des Backend-Servers ein. Das muss korrigiert werden. um diesen Fehler zu vermeiden. Wenden Sie sich gegebenenfalls an Ihr Backend-Team, beheben Sie dieses Problem.

Wenn Sie weitere Unterstützung vom Apigee Edge-Support benötigen, Weitere Informationen finden Sie unter Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, stellen Sie Folgendes zusammen: Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

  • Name der Organisation
  • Name der Umgebung
  • API-Proxy-Name
  • Vollständiger curl-Befehl zum Reproduzieren des 415-Fehlers
  • Ablaufverfolgungsdatei für API-Anfragen

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

  • Vollständige Fehlermeldung für fehlgeschlagene Anfragen
  • Name der Umgebung
  • API-Proxy-Bundle
  • Ablaufverfolgungsdatei für API-Anfragen
  • NGINX-Zugriffslogs /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Wo:ORG, ENV und PORT# werden ersetzt durch tatsächliche Werte.

  • Systemprotokolle des Message Processor /opt/apigee/var/log/edge-message- processor/logs/system.log