Diese Seite wurde von der Cloud Translation API übersetzt.

413 Anfrageentität zu groß – TooBigBody

<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 413 Request Entity Too Large ab mit dem Fehlercode protocol.http.TooBigBody als Antwort für API-Aufrufe.

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 413 Request Entity Too Large

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn die Nutzlastgröße, die von der Clientanwendung im Rahmen eines Die HTTP-Anfrage überschreitet das zulässige Limit in Apigee Edge .

Mögliche Ursachen für diesen Fehler :

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Größe der Anfragenutzlast überschreitet das zulässige Limit	Die von der Clientanwendung als Teil der HTTP-Anfrage an Apigee Edge gesendete Nutzlastgröße das Limit in Apigee Edge überschreitet.	Edge-Nutzer von öffentlichen und privaten Clouds
Größe der Anfragenutzlast überschreitet das zulässige Limit nach Dekomprimierung	Die Nutzlastgröße, die von der Clientanwendung im komprimierten Format als Teil von HTTP gesendet wird Anfrage an Apigee Edge überschreitet das zulässige Limit, wenn es von Apigee Edge dekomprimiert wird.	Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Techniken, um diesen Fehler zu diagnostizieren:

API-Monitoring

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

<ph type="x-smartling-placeholder"></ph> Melden Sie sich in der Apigee Edge-Benutzeroberfläche als Nutzer mit einem Rolle.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
Sie können den Proxy-Filter auswählen, um den Fehlercode einzugrenzen.
Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
Wählen Sie eine Zelle mit dem Fehlercode protocol.http.TooBigBody und Statuscode 413wie unten gezeigt:
Informationen über den Fehlercode protocol.http.TooBigBody werden angezeigt als (siehe unten):
Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage. Wählen Sie dann im Logs enthält, sehen Sie sich die folgenden Details an :
Unkomprimiert

Szenario 1: unkomprimierte Nutzlast der Anfrage

Achten Sie im Fenster „Logs“ auf die folgenden Details:
- Statuscode: 413
- Fehlerquelle: proxy
- Fehlercode: protocol.http.TooBigBody.
- Anfragelänge(Byte): 15360440 (~15 MB)
Wenn die Fehlerquelle den Wert proxy hat , gibt der Fehlercode den Wert protocol.http.TooBigBody und Request Length hat größer als 10 MB ist, bedeutet das, dass die HTTP-Anfrage vom Client eine Nutzlastgröße der Anfrage größer als das zulässige Limit in Apigee.
Komprimiert

Szenario 2: In komprimierter Form gesendete Anfrage-Nutzlast

Im Fenster Logs werden die folgenden Details angezeigt:
- Statuscode: 413
- Fehlerquelle: proxy
- Fehlercode: protocol.http.TooBigBody.
- Anfragelänge(Byte): 15264 (~15 KB)
Wenn die Fehlerquelle den Wert proxy hat , gibt der Fehlercode den Wert protocol.http.TooBigBody hat und die Anfragelänge den Wert kleiner als 10 MB ist, bedeutet dies, dass die HTTP-Anfrage vom Client eine die unter dem zulässigen Grenzwert im komprimierten Format liegt, aber der Nutzlastgröße ist im unkomprimierten Zustand von Apigee größer als das zulässige Limit.

Trace

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

Aktivieren Sie die Trace-Sitzung und entweder <ph type="x-smartling-placeholder">
- Warten Sie, bis der Fehler 413 Request Entity Too Large auftritt, oder
- Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus und reproduzieren Sie 413 Request Entity Too Large Fehler
Achten Sie darauf, dass Alle Ablaufinformationen anzeigen aktiviert ist.
Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
Gehen Sie zur Phase Request Received from Client.
Unkomprimiert

Szenario 1: unkomprimierte Nutzlast der Anfrage

Beachten Sie die folgenden Informationen:
- Content-Encoding: nicht vorhanden
- Inhaltslänge: 15360204
Komprimiert

Szenario 2: In komprimierter Form gesendete Anfrage-Nutzlast

Beachten Sie die folgenden Informationen:
- Content-Encoding: gzip
- Inhaltslänge: 14969
- Inhaltstyp: application/x-gzip
Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.
Sie finden den Fehler normalerweise in einem Ablauf nach der Anfrage empfangen von Client-Phase wie unten gezeigt:
Notieren Sie sich den Wert des Fehlers aus dem Trace. Der obige Beispiel-Trace zeigt Folgendes: <ph type="x-smartling-placeholder">
- Fehler: Body buffer overflow
- error.class::com.apigee.errors.http.user.RequestTooLarge
Gehen Sie zu Antwort an Client gesendet und notieren Sie sich die Fehlerwerte aus dem Trace. Der folgende Beispiel-Trace zeigt Folgendes:
- Fehler: 413 Request Entity Too Large
- Fehlerinhalt: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.
Scrollen Sie im Abschnitt Phase Details (Phasendetails) nach unten zu Variables Read (Lesen von Variablen).
Ermitteln Sie den Wert der Variablen client.received.content.length , die Folgendes angibt: <ph type="x-smartling-placeholder">
- Die tatsächliche Größe der Anfragenutzlast, wenn sie im unkomprimierten Format gesendet wird.
- Die Größe der Anfragenutzlast nach der Dekomprimierung durch Apigee, wenn die Nutzlast im komprimierten Format gesendet. Er entspricht immer dem Wert der zulässigen Limit von 10 MB.
<ph type="x-smartling-placeholder">
</ph> Hinweis: Möglicherweise wird ein Content-Length-Fehlerheader angezeigt, der die Größe der und nicht die Anfragenutzlast. Für diesen Fehler müssen wir den Wert der in der Variablen client.received.content.length angegeben ist.

Unkomprimiert

Szenario 1: Nutzlast in unkomprimierter Form anfordern

Variable „client.received.content.length“: 15360204

Komprimiert

Szenario 2: Nutzlast im komprimierten Format anfordern

Variable „client.received.content.length“: 10489856

In der folgenden Tabelle wird erläutert, warum der Fehler 413 von Apigee zurückgegeben wird: die beiden Szenarien basierend auf dem Wert der Variable "client.received.content.length":

Szenario	Wert von client.received.content.length	Fehlerursache
Nutzlast in unkomprimiertem Format anfordern	~15 MB	Größe > maximal 10 MB zulässig.
Anfrage-Nutzlast im komprimierten Format	~10 MB	Größenbeschränkung bei Dekomprimierung überschritten <ph type="x-smartling-placeholder"> </ph> Hinweis: Die tatsächliche Größe der Nutzlast nach der Dekomprimierung kann deutlich mehr als 10 MB. Apigee beendet die Dekomprimierung jedoch, sobald die Größe der unkomprimierten Datei data überschreitet das Limit von 10 MB (Standardlimit) und wird mit dem Fehler zurückgegeben.

NGINX

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

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

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
<ph type="x-smartling-placeholder">
</ph> Hinweis: Ersetzen Sie ORG, ENV und PORT# durch die tatsächlichen Werte.
Suchen Sie nach 413-Fehlern während einer bestimmten Dauer (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 413

Wenn Sie 413-Fehler mit dem X-Apigee-fault-code finden den Wert von protocol.http.TooBigBody und dann den Wert des X-Apigee-fault-source.

Unkomprimiert

Szenario 1 : Größe der Nutzlast im unkomprimierten Format anfordern

Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code :

Antwortheader	Wert
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-sourc	`policy`

Beachten Sie die Anfragelänge:15360440 (14,6 MB > zulässiges Limit)

Komprimiert

Szenario 2 : Größe der Nutzlast im komprimierten Format anfordern

Der obige Beispieleintrag aus dem NGINX-Zugriffsprotokoll enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code

Antwortheader	Wert
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-source	`policy`

Beachten Sie die Anfragelänge:15264 (14,9 KB < zulässiges Limit)

In diesem Szenario gibt Apigee Edge 413 zurück, obwohl die Die Anfragelänge liegt unter dem zulässigen Limit, da die Anfrage möglicherweise im komprimierten Format gesendet wurden und die Größe der Nutzlast die bei der Dekomprimierung durch Apigee Edge.

Ursache: Die Größe der Anfrageutzlast liegt über dem zulässigen Grenzwert

Diagnose

Bestimmen Sie den Fehlercode, die Fehlerquelle und die Größe der Anfrageutzlast für die bei Verwendung von API-Überwachungs-, Trace-Tool- oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte mit Szenario 1 (unkomprimiert).
Wenn die Fehlerquelle den Wert policy oder proxy hat, ist dies gibt an, dass die von der Clientanwendung an Apigee gesendete Anfragenutzlastgröße größer als das zulässige Limit in Apigee Edge.
Überprüfen Sie die Request Payload Size (Größe der Anfrageutzlast), wie in Schritt 1 ermittelt.
- Wenn die Nutzlastgröße > 10 MB zulässig ist, ist dies die Ursache für den Fehler.
- Wenn die Nutzlastgröße < 10 MB zulässig ist, dann ist es möglich, Payload wird in einem komprimierten Format übergeben. Wechseln Sie zu . Ursache: Die Größe der Anfragenutzlast überschreitet nach der Dekomprimierung das zulässige Limit.
Sie können auch überprüfen, ob die Größe der Anfragenutzlast tatsächlich > 10 MB, Limit von Überprüfen Sie die Anfrage mit den folgenden Schritten: <ph type="x-smartling-placeholder">
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">
  1. Überprüfen Sie die Größe der in der Anfrage übergebenen Nutzlast.
  2. Wenn Sie feststellen, dass die Größe der Nutzlast größer ist als die in Apigee Edge zulässig ist, ist das die Ursache des Problems.

Auflösung

Gehe zu Lösung.

Ursache: Die Größe der Anfrageutzlast überschreitet nach der Dekomprimierung das zulässige Limit.

Wenn die Anfragenutzlast in einem komprimierten Format gesendet wird und der Anfrageheader Content-Encoding ist auf gzip, Apigee dekomprimiert die Anfrage. Payload. Wenn Apigee während der Dekomprimierung feststellt, dass die Größe der Nutzlast größer ist als 10 MB, <ph type="x-smartling-placeholder"></ph> den zulässigen Grenzwert erreicht, stoppt die weitere Dekomprimierung und antwortet sofort mit 413 Request Entity Too Large mit Fehlercode protocol.http.TooBigBody.

Diagnose

Ermitteln Sie den Fehlercode, die Fehlerquelle und die Größe der Anfrageutzlast. . Häufige Diagnoseschritte mit Szenario 2 (komprimiert).
Wenn die Fehlerquelle den Wert policy oder proxy hat, dann: gibt an, dass die von der Clientanwendung an Apigee gesendete Anfragenutzlastgröße größer ist. als das zulässige Limit in Apigee Edge.
Prüfen Sie die Größe der Anfragenutzlast wie in Schritt 1 ermittelt.
- Wenn die Nutzlastgröße > 10 MB zulässig ist, ist dies die Ursache für den Fehler.
- Wenn die Nutzlastgröße < 10 MB zulässig ist, dann ist es möglich, Payload wird in einem komprimierten Format übergeben. Überprüfen Sie in diesem Fall die unkomprimierte Größe des komprimierter Anforderungsnutzlast.
Sie können überprüfen, ob die Anfrage vom Client in einem komprimierten Format gesendet wurde und der Die unkomprimierte Größe lag mit einem der folgenden Elemente über dem zulässigen Grenzwert Methoden:
Trace

So führen Sie eine Validierung mit dem Trace-Tool durch:
1. Wenn Sie einen Trace für die fehlgeschlagene Anfrage erfasst haben, folgen Sie den Schritten in Trace und <ph type="x-smartling-placeholder">
  1. Wert der Variablen client.received.content.length ermitteln
  2. Überprüfe, ob die Anfrage vom Client die Content-Encoding: gzip -Header
2. Wenn der Wert der Variablen client.received.content.length größer ist als der Wert 10 MB <ph type="x-smartling-placeholder"></ph> das zulässige Limit und den Anfrageheader Content-Encoding: gzip, , ist das die Ursache für diesen Fehler.
Tatsächliche Anfrage

So validieren Sie die Anfrage anhand der tatsächlichen Anfrage:
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">
  1. Prüfen Sie die Größe der in der Anfrage übergebenen Nutzlast zusammen mit dem Der Content-Encoding-Header wurde in der Anfrage gesendet.
  2. Prüfen Sie, ob die unkomprimierte Größe der Nutzlast größer ist als die zulässiges Limit in Apigee Edge
    
    Beispielanfrage:
    
    curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
    
    In diesem Fall liegt die Datei test15mbfile.gz unter der Größenbeschränkung. Die Größe der unkomprimierten Datei test15mbfile beträgt jedoch ~15 MB und Der Content-Encoding-Header ist gzip.
    
    Wenn Sie einen anderen Client verwenden, rufen Sie die Clientlogs ab, um die Größe der Nutzlast zu ermitteln. gesendet wird und der Header Content-Encoding auf gzip gesetzt ist.
Message Processor-Logs

So validieren Sie mit Message Processor-Logs:
<ph type="x-smartling-placeholder">
</ph> Hinweis: Die Anleitung in diesem Abschnitt gilt nur für Edge Private Cloud-Nutzer.
1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von Message Processor-Logs ermitteln, enthält die wichtigsten Informationen zu HTTP-413-Fehlern.
2. Prüfen Sie die Message Processor-Logs:
  
  /opt/apigee/var/log/edge-message-processor/logs/system.log
3. Suchen Sie nach 413-Fehlern während einer bestimmten Dauer (wenn die oder Anfragen mit 413 fehlschlagen.
  
  Sie können die folgenden Suchzeichenfolgen verwenden:
```
grep -ri "chunkCount"
```
```
grep -ri "RequestTooLarge"
```
4. Ihnen werden Zeilen von system.log angezeigt, die der folgenden ähneln: TotalRead und chunkCount können in Ihrem Fall variieren:
```
2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
```
5. Während der Dekomprimierung, sobald der Message Processor die Gesamtmenge Lesebyte ist > 10 MB haben, hält er an und gibt die folgende Zeile aus:
```
Message is too large.  TotalRead 10489856 chunkCount 2570
```
  Es impliziert, dass die Anfragenutzlastgröße größer als 10 MB ist und Apigee wirft Der Fehler RequestTooLarge, wenn die Größe das Limit von 10 MB überschreitet mit Fehlercode als protocol.http.TooBigBody
  <ph type="x-smartling-placeholder">
  </ph> Hinweis: Sie sehen die obige Zeile in den Message Processor-Protokollen auch dann, wenn Sie den Nutzlast der Anfrage in unkomprimiertem Format. Der einzige Unterschied ist, dass TotalRead enthält die tatsächliche Größe der Anfragenutzlast in diesem Szenario.

Auflösung

Größe korrigieren

Option 1 [empfohlen]: Korrigieren Sie die Clientanwendung so, dass sie keine Nutzlastgröße sendet, die größer als die zulässiges Limit

Analysieren Sie den Grund dafür, dass der jeweilige Client die Anfrage-/Nutzlastgröße über dem zulässigen Wert sendet. wie unter Grenzwerte definiert.
Wenn dies nicht erwünscht ist, ändern Sie Ihre Clientanwendung so, dass sie Anfrage / Nutzlast sendet. die Größe unter dem zulässigen Grenzwert liegt.

Im oben beschriebenen Beispiel können Sie das Problem beheben, indem Sie eine kleinere Datei Nehmen wir als Beispiel die Nutzlast test5mbfile (mit einer Größe von 5 MB), wie unten dargestellt:
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
Wenn dies wünschenswert ist und Sie eine Anforderung/Nutzlast über das zulässige Limit hinaus senden möchten, gehen Sie zu die nächsten Optionen.

Muster für signierte URLs

Option 2 [empfohlen]: Muster für signierte URLs in einem Apigee-JavaCallout verwenden

Für Nutzlasten, die größer als 10 MB sind, empfiehlt Apigee, ein Muster für signierte URLs innerhalb eines Apigee JavaCallout, illustriert durch das <ph type="x-smartling-placeholder"></ph> Edge Callout: Signed URL Generator (Beispiel für einen Generator für signierte URLs) auf GitHub (in englischer Sprache).

Streaming

Option 3 : Streaming verwenden

Wenn Ihr API-Proxy sehr große Anfragen und/oder Antworten verarbeiten muss, können Sie streaming in Apigee.

CwC

Option 4 : CwC-Attribut verwenden, um das Pufferlimit zu erhöhen

Verwenden Sie diese Option nur, wenn Sie keine der empfohlenen Optionen verwenden können, da sie wenn die Standardgröße erhöht wird.

Apigee bietet eine CwC-Attribut ein, mit dem sie die Nutzlastgröße für Anfragen und Antworten. Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> Limit für die Nachrichtengröße auf dem Router oder Message Processor festlegen

Limits

Apigee erwartet, dass die Clientanwendung und der Backend-Server keine Nutzlastgrößen senden, die größer als der für Request/response size dokumentierte zulässige Höchstwert in Apigee Edge-Limits.

Wenn Sie ein Public Cloud-Nutzer sind, gilt die Höchstgrenze für Anfragen und Antworten Nutzlastgröße entsprechend der Dokumentation für Request/response size in Apigee Edge-Limits.
Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise die Standardeinstellung Limit für die Nutzlastgröße von Anfragen und Antworten (auch wenn dies nicht empfohlen wird). Sie können die maximale Nutzlastgröße für Anfragen bestimmen, indem Sie die Anweisungen in So prüfen Sie das aktuelle Limit.

Wie kann ich das aktuelle Limit prüfen?

In diesem Abschnitt wird erläutert, wie du überprüfst, ob die Property HTTPRequest.body.buffer.limit wurde mit einem neuen Wert für die Message Processors aktualisiert.

Suchen Sie auf dem Message Processor-Computer nach der Eigenschaft HTTPRequest.body.buffer.limit im Verzeichnis /opt/apigee/edge-message- processor/conf und prüfen Sie mit dem folgenden Befehl, welcher Wert festgelegt wurde: Befehl:
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

Das Ergebnis des obigen Befehls sieht wie folgt aus:

/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

Beachten Sie in der obigen Beispielausgabe, dass die Eigenschaft HTTPRequest.body.buffer.limit wurde auf den Wert 10m festgelegt in http.properties

Dies gibt an, dass das Limit für die Größe der Anfragenutzlast, das in Apigee for Private konfiguriert ist, Cloud ist 10 MB groß.

Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, gehen Sie zu Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

Erfassen Sie die folgenden Diagnoseinformationen und wenden Sie sich 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 Fehlers 413
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 Organisation
Name der Umgebung
API-Proxy-Bundle
Ablaufverfolgungsdatei für fehlgeschlagene API-Anfragen
Vollständiger curl-Befehl zum Reproduzieren des Fehlers 413
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

413 Anfrageentität zu groß – TooBigBody

Symptom

Fehlermeldung

Mögliche Ursachen

Allgemeine Diagnoseschritte

API-Monitoring

Unkomprimiert

Komprimiert

Trace

Unkomprimiert

Komprimiert

Unkomprimiert

Komprimiert

NGINX

Unkomprimiert

Komprimiert

Ursache: Die Größe der Anfrageutzlast liegt über dem zulässigen Grenzwert

Diagnose

Auflösung

Ursache: Die Größe der Anfrageutzlast überschreitet nach der Dekomprimierung das zulässige Limit.

Diagnose

Trace

Tatsächliche Anfrage

Message Processor-Logs

Auflösung

Größe korrigieren

Muster für signierte URLs

Streaming

CwC

Limits

Wie kann ich das aktuelle Limit prüfen?

Erfassen von Diagnoseinformationen erforderlich