* 仕様書から

[FIG[
[FIGCAPTION[
[2] RFC 2068 & 2616 (HTTP/1.1) 10.4.15 414 Request-URI Too Long
]FIGCAPTION]

> The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query
information, when the client has descended into a [DEL[URL]] [INS[URI]] "black hole" of
redirection (e.g., a redirected [DEL[URL]] [INS[URI]] prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.

サーバーは、その解釈する意思がある長さよりも [CODE(ABNF)[[[Request-URI]]]]
が長いために、要求をサービスするのを拒否しています。
この稀な状態は、クライアントが不適切にも [CODE(HTTP)[[[POST]]]] 要求を長い問合せ情報をつけた
[CODE(HTTP)[[[GET]]]] 要求に変換しているときや、
クライアントが URI のリダイレクト「ブラック・ホール」に落下してゆくとき
(例えば、リダイレクトされる URI の接頭辞が自身の接尾辞を指示しているとか)、
或いは固定長バッファーを [CODE(ABNF)[Request-URI]] を読んだり処理したりするのに使っている幾つかのサーバーにあるセキュリティー・ホールを突いて攻撃しているクライアントにサーバーが攻撃されている時に限って起きることでしょう。

* RFC の部分の License

[[RFCのライセンス]]
]FIG]

* メモ

[1] [[URI]] の長さには本来制限はありません。
HTTP においても、処理系的にやむを得ない場合を除いて任意の長さを扱えるようにするべきだとどっか他の章に書いてあったと思います。

現実には、 [[WWWブラウザ]]で一定長までしか扱えないのがよく使われていますし、
サーバー側にしてもファイル・システムに写像しているのならファイル・システム側のファイル名の長さ制限に引っかかることが考えられます。
[WEAK[(但し、ファイル・システムの制限ならサーバー側のどうでも良い事情ですから、隠匿して [CODE(HTTP)[[[404]]]] でも送っておくのが筋でしょう。)]]