[Lösung des Problems] 413 Fehler 413 Request Entity Too Large Die Schnittstelle gibt 413 zurück und meldet 413nginx

Blog-Hintergrund: JAVA-Projekt, das Frontend wollte einen praktischen Rich-Text erstellen, daher wurden viele Bilder direkt in die Base64-Codierung konvertiert und direkt gespeichert. Das Feld ist vom Typ Langtext.
Dieses Problem tritt normalerweise auf, wenn das HTTP-Anforderungsobjekt zu groß ist. .

Fehlerbehebung

1. Wenn es zu lang ist, ändern Sie den Varchar-Typ in den Longtext-Typ.
2. Wenn Sie immer noch Zweifel haben, dass der Text zu lang ist, suchen Sie nach der maximalen Länge des Langtexts.

Die maximalen Längen der drei Texttypen in MySQL sind wie folgt:
● TEXT 65.535 Bytes ~64 KB
● MEDIUMTEXT 16.777.215 Bytes ~16 MB
● LONGTEXT 4.294.967.295 Bytes ~4 GB

Es war definitiv nicht zu lang, also habe ich die Anfrage direkt online gelesen. . Sehr direkt. .
Die Standardgröße der Nginx-Anfrage muss geändert werden

Lösung

1. Ändern Sie die Nginx-Konfigurationsdatei nginx.conf

Begrenzen Sie die Größe des Anforderungstexts, der Standardwert ist 1 m. Wenn er die festgelegte Größe überschreitet, wird ein 413-Fehler zurückgegeben.

 client_max_body_size     50m; 

Das Zeitlimit für das Lesen von Anforderungsheadern. Wenn es die festgelegte Größe überschreitet, wird ein 408-Fehler zurückgegeben.

 client_header_timeout    1m;

Das Zeitlimit für das Lesen der Anforderungsentität. Wenn die festgelegte Größe überschritten wird, wird ein 413-Fehler zurückgegeben.

 client_body_timeout      1m;

Die http-Anfrage kann vom Container (Tomcat, Netty usw.) nicht sofort verarbeitet werden und wird im Nginx-Ausstehenden-Pool abgelegt, der auf die Verarbeitung wartet. Dieser Parameter ist die maximale Wartezeit. Der Standardwert beträgt 60 Sekunden. Die offizielle Empfehlung lautet, dass die längste Zeit 75 Sekunden nicht überschreiten sollte.

 proxy_connect_timeout     60s;

Nachdem die http-Anfrage vom Container (Tomcat, Netty usw.) verarbeitet wurde, wartet Nginx auf das Verarbeitungsergebnis, bei dem es sich um die vom Container zurückgegebene Antwort handelt. Dieser Parameter ist die Antwortzeit des Servers. Der Standardwert beträgt 60 Sekunden

 proxy_read_timeout      1m;

Nachdem die http-Anfrage vom Server verarbeitet wurde, beträgt die Zeit, die für die Rückgabe der Daten an Nginx benötigt wird, standardmäßig 60 Sekunden.

 proxy_send_timeout      1m;

(1) Es kann in http{ } festgelegt werden: client_max_body_size 20m;
(2) Es kann auch in server{ } festgelegt werden: client_max_body_size 20m;
(3) Es kann auch in location{ } festgelegt werden: client_max_body_size 20m;

http{} steuert alle von Nginx empfangenen Anfragen.
Wenn es in server{} konfiguriert ist, steuert es die Größe der vom Server empfangenen Anforderungspakete.
Bei einer standortbezogenen Konfiguration wird die Paketgrößenbeschränkung nur für Anfragen wirksam, die den Standort-Routing-Regeln entsprechen.

nginx.conf-Datei:

http{
    
    
#控制全局nginx所有请求报文大小
#client_max_body_size   20m;
                 server{
    
    
 #控制该server的所有请求报文大小
 #client_max_body_size   20m;
                         location a {
    
    
                         }
                         location b{
    
    
 #控制满足该路由规则的请求报文大小
 #client_max_body_size   20m;
                         }
                 }
                 server {
    
    
                 }
      }

2. Nachdem das Update abgeschlossen ist, muss Nginx neu gestartet werden.

 sudo systemctl restart nginx

3. Andere Möglichkeiten

In Tomcat
Tomcats server.xml begrenzt der Parameter maxPostSize den Maximalwert des Post-Request-Nachrichtentexts. Der Standardwert ist 2M (2097152 (2 Megabyte).)
Wenn er in server.xml nicht konfiguriert ist, ist er der Standardparameter Wert.

Der Front-End-
Knotendienst verwendet das Egg.js-Framework, und die Konfiguration jsonLimit von Egg begrenzt die Größe des JSON-Nachrichtentexts.
Wenn nicht konfiguriert, ist der Standardwert 100.000.

Referenz: https://blog.csdn.net/weixin_32006353/article/details/115981342
https://blog.csdn.net/z69183787/article/details/83070275