回答:
いいえ、HTTPは制限を定義していません。ただし、ほとんどのWebサーバーは、受け入れるヘッダーのサイズを制限しています。たとえば、Apacheではデフォルトの制限は8KB ですが、IISでは16Kです。413 Entity Too Largeヘッダーサイズがその制限を超えると、サーバーはエラーを返します。
vartecが前述したように、HTTP仕様は制限を定義していませんが、多くのサーバーはデフォルトで制限を定義しています。つまり、実際には、下限は8Kです。ほとんどのサーバーでは、この制限はリクエスト行とすべてのヘッダーフィールドの合計に適用されます（Cookieを短くしてください）。
nginxがデフォルトでシステムページサイズを使用することは注目に値します。これは、ほとんどのシステムで4Kです。この小さなプログラムで確認できます：
pagesize.c：
#include <unistd.h>
#include <stdio.h>
int main() {
int pageSize = getpagesize();
printf("Page size on your system = %i bytes\n", pageSize);
return 0;
}
でコンパイルしてgcc -o pagesize pagesize.c実行し./pagesizeます。Linodeの私のubuntuサーバーは忠実に答えを4kと通知しています。
LimitRequestLine、LimitRequestFieldSize適用されます。「...の合計」ではなく
セクション2.5で説明されているように、HTTPは、各ヘッダーフィールドの長さまたはヘッダーセクション全体の長さに対して事前定義の制限を設けていません。個々のヘッダーフィールドの長さに関するさまざまなアドホック制限が実際に見られますが、多くの場合、特定のフィールドセマンティクスによって異なります。
HTTPヘッダー値はサーバーの実装によって制限されます。Http仕様はヘッダーサイズを制限しません。
処理したいサイズより大きいリクエストヘッダーフィールドまたはフィールドセットを受信するサーバーは、適切な4xx（クライアントエラー）ステータスコードで応答する必要があります。このようなヘッダーフィールドを無視すると、密輸攻撃を要求するサーバーの脆弱性が増加します（セクション9.5）。
413 Entity Too Largeこれが発生すると、ほとんどのサーバーが4xxエラーまたは適切な4xxエラーを返します。
クライアントは、フィールドのセマンティクスがメッセージのフレーミングまたは応答のセマンティクスを変更せずにドロップされた値を安全に無視できるようなものである場合、クライアントが処理したいより大きい受信ヘッダーフィールドを破棄または切り捨てることができます。
上限のないHTTPヘッダーサイズは、サーバーを攻撃にさらしたままにし、オーガニックトラフィックを処理する能力を低下させる可能性があります。
また、多くのヘッダーの場合の502/400の理由は、サイズに関係なく多数のヘッダーが原因である場合があることもわかりました。ドキュメントから
tune.http.maxhdrリクエストのヘッダーの最大数を設定します。リクエストにこの値（最初の行を含む）より大きい数のヘッダーが含まれている場合、「400 Bad Request」ステータスコードで拒否されます。同様に、大きすぎる応答は「502 Bad Gateway」でブロックされます。広く展開されているApacheサーバーが同じ制限を使用していることを考えると、デフォルト値は101で、これはすべての用途に十分です。この制限をさらに押して、バグのあるアプリケーションが修正されるまでに一時的に動作するようにすると便利です。新しいヘッダーはセッションごとに32ビットのメモリを消費するので、この制限を高くしすぎないように注意してください。
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.http.maxhdr