[419] [DFN[[CODE(HTTP)[[[414]]]]]] ([DFN[[[URI Too Long]]]]) は、 [[要求URL]]が長すぎるため処理できないことを表す[[状態符号]]です。 * 仕様書 [REFS[ - [416] '''[CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) ''' - [415] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ]REFS] * 意味 [417] [CODE(HTTP)[[[414]]]] は、[[要求対象]]が長くて[[鯖]]が解釈したくないため[[要求]]を[[拒絶]]したことを示します [SRC[>>416]]。 [6] 厳密に言えば[[要求対象]]と[[要求URL]]は異なるものですが ([SEE[ [[要求対象]] ]])、 [CODE[414]] を送る、送らないの判定に関して言えば大差はありません。 [[サーバー]]は、 [[要求対象]]が長すぎると検知したときでも、 [[要求URL]]が長すぎると判断したときでも、 どちらでも [CODE[414]] を送ることが出来ます。 [7] 長い、短いの判断は完全に[[サーバー]]に委ねられていて、 一定している必要もありません。例えば同じ [[URL]] を何回か送信してそのたびに正常処理と [CODE[414]] のどちらかが返ってきても構いませんし (そんな必要があるか、 それが良い設計であるかは別問題ですが)、 同じ[[起源サーバー]]上のある [[path]] では [CODE[414]] になる長さが他の [[path]] のとき正常処理になっても構いません。 ;; [8] 従って[[クライアント]]は[[サーバー]]の判定基準を [CODE[414]] [[応答]]か否かによって完全に知ることは出来ませんし、 そのような予測を期待されてもいません。 ;; [9] もちろん、現実的な実装手法なら、一度 [CODE[414]] になった[[要求URL]]より長いものは [CODE[414]] が返ってくる可能性が高いという一般論での予測は十分可能です。 が、汎用の [[HTTPクライアント]]ライブラリーならそれを前提にした実装をしてはいけません。 * 文脈 [405] [[構文解析]]したい [[URI]] の長さを超える[[要求対象]]を受信した[[鯖]]は、 [CODE(HTTP)[[[414]]]] を返さなければ[['''なりません''']] [SRC[>>3]]。 [420] 仕様上は明確な上限値があるわけではなく、[[サーバー]]が決めることができます。 長さ制限については[[要求対象]], [[URLの長さ]]の項を参照してください。 * 処理 [418] [CODE(HTTP)[[[414]]]] は[[キャッシュ可能]]です [SRC[>>416]]。 [1] 理論上は[[クライアント]]は [CODE[414]] を受信したら[[要求URL]] を短縮して再度[[要求]]を作り直して送信することができます。 しかし現実的には[[要求URL]] に冗長な情報があって、それを削って再試行できることがわかっているような状況はさほど多くありません。 特定の[[応用]]の専用の[[クライアント]]で、しかも省略可能な情報を送信するかなり特殊な状況を除けば、 [CODE[414]] を[[受信]]したらその[[要求]]は完全に失敗したものとして扱うことになります。 ;; [5] [[サーバー]]の上限を超えて長い[[引数]]を持つ[[要求]]をしなければならないような[[応用]]では、 [CODE[POST]] と[[応答本体]] ([CODE[application/x-www-form-urlencoded]] や [CODE[multipart/form-data]]) を使うのが定石となっています。 [[HTTP]] としては [CODE[GET]] や [CODE[POST]] で[[要求URL]]で[[引数]]を指定するのと [CODE[POST]] で[[応答本体]]で[[引数]]を指定するのは異なるものですが、 多くの[[Webアプリケーション]]用[[ライブラリー]]は同一視して透過的に扱えるようにしています。 [SEE[ [[query parameter]] ]] [4] [[Webブラウザー]]の [[navigate]] で [CODE[414]] を受信したときは、 [CODE[400]] など他の [CODE[4[VAR[xx]]]] の[[応答]]と同様に、 普通の一般的な[[応答]]として表示などをすることになります。 [SEE[ [[fetch]] ]] * 歴史 [FIG(quote)[ [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]] を読んだり処理したりするのに使っている幾つかのサーバーにあるセキュリティー・ホールを突いて攻撃しているクライアントにサーバーが攻撃されている時に限って起きることでしょう。 ]FIG] [REFS[ - [3] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) ]REFS] * メモ