記事ディレクトリ
ブログの背景: JAVA プロジェクトでは、フロントエンドが便利なリッチ テキストを作成したいと考えていたため、多くの画像が直接 Base64 エンコードに変換され、直接保存されました。フィールドはロングテキストタイプです。
この問題は通常、http 要求オブジェクトが大きすぎる場合に発生します。。
トラブルシューティング
1. 長すぎる場合は、varchar型をlongtext型に変更します。
2. それでも長すぎると思われる場合は、長文の最大長を検索します。
mysql の 3 つのテキスト タイプの最大長は次のとおりです。
● TEXT 65,535 バイト ~64kb
● MEDIUMTEXT 16,777,215 バイト ~16Mb
● LONGTEXT 4,294,967,295 バイト ~4Gb
決して長すぎるものではなかったので、オンラインで直接リクエストを読みました。。とても直接的です。。
nginxリクエストのデフォルトサイズを変更する必要がある
解決
1. nginx 設定ファイル nginx.conf を変更します。
リクエストボディのサイズを制限します。デフォルトは 1m です。設定されたサイズを超えると、413 エラーが返されます。
client_max_body_size 50m;
リクエスト ヘッダーの読み取りのタイムアウト。設定されたサイズを超えると、408 エラーが返されます。
client_header_timeout 1m;
リクエスト エンティティの読み取りのタイムアウト。設定されたサイズを超えると、413 エラーが返されます。
client_body_timeout 1m;
http リクエストはコンテナ (tomcat、netty など) によってすぐに処理できず、nginx 保留プールに置かれて処理を待機します。このパラメータは最大待機時間です。デフォルトは 60 秒です。公式の推奨では、最長時間が 75 秒を超えないようになっています。
proxy_connect_timeout 60s;
http リクエストがコンテナ (tomcat、netty など) によって処理された後、nginx はコンテナから返される応答である処理結果を待ちます。このパラメータはサーバーの応答時間で、デフォルトは 60 秒です。
proxy_read_timeout 1m;
http リクエストがサーバーによって処理された後、データが Nginx に返されるまでにかかる時間はデフォルトで 60 秒です。
proxy_send_timeout 1m;
(1) http{ } にも設定可能: client_max_body_size 20m;
(2) Server{ } にも設定可能: client_max_body_size 20m;
(3) location{ } にも設定可能: client_max_body_size 20m;
http{} は、nginx によって受信されるすべてのリクエストを制御します。
サーバーで設定されている場合、サーバーが受信するリクエスト パケットのサイズが制御されます。{}
ロケーションで構成されている場合、パケット サイズ制限はロケーション ルーティング ルールに一致するリクエストに対してのみ有効になります。
nginx.conf ファイル:
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. アップデートが完了したら、nginx を再起動する必要があります。
sudo systemctl restart nginx
3. 他の可能性
Tomcat
Tomcat の server.xml では、maxPostSize パラメータによってポスト リクエスト メッセージ本文の最大値が制限されます。デフォルト値は 2M (2097152 (2 メガバイト)) です。server.xml で設定されていない場合、これがデフォルトのパラメータになります
。価値。
フロントエンド
ノード サービスは Egg.js フレームワークを使用し、Egg の構成 jsonLimit によって json メッセージ本文のサイズが制限されます。
構成されていない場合、デフォルトは 100k です。
参考:https://blog.csdn.net/weixin_32006353/article/details/115981342
https://blog.csdn.net/z69183787/article/details/83070275