* 仕様書から ** RFC 1945 (HTTP/1.0) 8.3; RFC 2068・2616 (HTTP/1.1) 9.5 POST > The POST method is used to request that the [DEL[[INS[{1945,2068}]] destination]] [INS[[INS[{2616}]] origin]] server accept the entity enclosed in the request as [DEL[[INS[{1945,2068,2616}]] a new subordinate of]] [INS[[INS[{Errata}]] data to be processed by]] the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: [CODE(HTTP)[POST]] 方式は、起源サーバーが要求に囲まれた[[実体]]を [CODE(ABNF)[[[Request-Line]]]] の [CODE(ABNF)[[[Request-URI]]]] で識別される[[資源]][DEL[の新しい付随物]][INS[で処理するデータ]]として受け入れることを要求するのに使います。 [CODE(HTTP)[POST]] は次の機能を覆う統一方式とできるように設計されています。 > - [DEL[[INS[{1945,2068}]] o]] [INS[[INS[{2616}]] -]] Annotation of existing resources; - [DEL[o]] [INS[-]] Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - [DEL[o]] [INS[-]] Providing a block of data, such as the result of submitting a form [DEL[ [3] ]], to a data-handling process; - [DEL[o]] [INS[-]] Extending a database through an append operation. - 既存の資源に注釈を付ける - [[掲示板]], [[ニュース組]], [[メイリング・リスト]]あるいは同様の記事の組へ投稿する - [[フォーム]]で送信する結果のような、データの塊をデータ取扱い過程に提供する - 付加操作を通じてデータベースを広げる > The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. [DEL[[INS[{1945,2068,2616}]] The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. [INS[{Errata で削除}]]]] [CODE(HTTP)[POST}] 方式で行われる実際の機能はサーバーにより決定され、]] 通常 [CODE(ABNF)[Request-URI]] に依存します。[DEL[投稿された実体は、[[ファイル]]がそれを含む[[ディレクトリ]]に付随するとか、[[ニュース]]記事が投稿されたニュース組に付随するとか、[[記録]]がデータベースに藤生するのと同じように、その [[URI]] に付随します。]] > [DEL[[INS[{1945}]] A successful POST does not require that the entity be created as a resource on the origin server or made accessible for future reference. That is, the]] [INS[The]] action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 [DEL[[INS[{1945}]] (ok)]] [INS[(OK)]] or 204 [DEL[[INS[{1945}]] (no content)]] [INS[(No Content)]] is the appropriate response status, depending on whether or not the response includes an entity that describes the result. ;[DEL[[CODE(HTTP)[POST]] が成功したからといって、その実体が[[起源サーバー]]で[[資源]]として作られたり、生来の参照で接続可能となる必要はありません。つまり、]] [CODE(HTTP)[POST]] 方式で行われる動作は結果として URI で識別できる資源にならないかもしれません。 この場合、応答が結果を説明する実体を含むか否かによって、 [CODE(HTTP)[[[200]]]] (了解) または [CODE(HTTP)[[[204]]]] (無内容) が適切な応答符号です。 > If a resource has been created on the origin server, the response [DEL[[INS[{1945}]] should]] [INS[SHOULD]] be 201 [DEL[[INS[{1945}]] (created)]] [INS[(Created)]] and contain an entity [DEL[[INS[{1945}]] (preferably of type "text/html")]] which describes the status of the request and refers to the new resource[INS[, and a Location header (see section 14.30)]]. 起源サーバーに資源が作られた場合は、応答は [CODE(HTTP)[[[201]]]] (作成せし) とし、 要求の状態を説明して新しい資源を参照する実体[INS[と、 [CODE(HTTP)[[[Location]]]] 頭]]を含む'''べきです'''。 [DEL[ > A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content. すべての HTTP/1.0 [CODE(HTTP)[POST]] 要求で妥当な [CODE(HTTP)[[[Content-Length]]]] が必要です。 HTTP/1.0 サーバーは、要求メッセージの内容の長さを決定できなければ [CODE(HTTP)[[[400]]]] (悪い要求) メッセージで応答するべきです。 > Applications must not cache responses to a POST request because the application has no way of knowing that the server would return an equivalent response on some future request. [[応用]]は、サーバーが将来の要求でも同等の応答を返すということを知る方法が応答にはないので、 [CODE(HTTP)[POST]] 要求への応答を[[キャッシュ]]してはなりません。 ]DEL] [INS[ > Responses to this method are not cach[INS[e]]able, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cach[INS[e]]able resource. この方式への応答は、応答が適切な [CODE(HTTP)[[[Cache-Control]]]] 頭欄または [CODE(HTTP)[[[Expires]]]] 頭欄を含んでいない限り[[キャッシュ可能]]ではありません。 しかし、利用者エージェントがキャッシュ可能資源を取り出すように指向するために [CODE(HTTP)[[[303]]]] (他を見よ) 応答を使えます。 > POST requests [DEL[must]] [INS[MUST]] obey the message transmission requirements set out in section 8.2. [CODE(HTTP)[POST]] 要求は8.2節のメッセージ転送要件に従わなければ'''なりません'''。 [INS[ > See section 15.1.3 for security considerations. 安全性について15.1.3節を参照。 ]INS] ]INS] *** Errata の変更事由 > The description of POST was broadened over time, and is not clear. [CODE(HTTP)[POST]] の説明は時間と共に広がり、明確ではありません。 ** RFC 2295 (HTTP 透過内容折衝) 12.2 Negotiation on transactions other than GET and HEAD [1] > If a resource is transparently negotiable, this only has an impact on the GET and HEAD transactions on the resource. It is not possible (under this specification) to do transparent content negotiation on the direct result of a POST request. 資源が透過折衝可能であるときには、これはその資源の [CODE(HTTP)[[[GET]]]] 及び [CODE(HTTP)[[[HEAD]]]] の処理にのみ影響します。 (この仕様書では) [CODE(HTTP)[[[POST]]]] 要求の直接の結果について透過内容折衝することは不可能です。 > However, a POST request can return an unnegotiated 303 (See Other) response which causes the user agent to do a GET request on a second resource. This second resource could then use transparent content negotiation to return an appropriate final response. The figure below illustrates this. しかし、 [CODE(HTTP)[POST]] 要求は利用者エージェントに2番目の資源に [CODE(HTTP)[GET]] 要求を行わせる折衝しない [CODE(HTTP)[[[303]]]] (他を見よ) 応答を返すことが出来ます。 この2番目の応答の方は透過内容折衝を使って適当な最終応答を返すことができます。 次の図はこれを図示しています。 > [PRE[ Server ______ proxy ______ proxy ______ user x.org cache cache agent < ------------------------------------- | POST http://x.org/cgi/submit |
| -------------------------------------- > 303 See Other | Location: http://x.org/result/OK | | < ------------------------------------- | GET http://x.org/result/OK | small Accept- headers | able to choose on behalf of user agent | ------------------------------------- > choice response with | ..result/OK.nl variant | displays OK.nl ]PRE] > See the HTTP/1.1 specification [1] for details on the 303 (See Other) status code. Note that this status code is not understood by some HTTP/1.0 clients. ** RFC の部分の License [[RFCのライセンス]] ** CGI [REFS[ - [405] [CITE@en[RFC 3875 - The Common Gateway Interface (CGI) Version 1.1]] ([TIME[2011-11-20 06:09:05 +09:00]] 版) ]REFS] * メモ [401] [CITE[POSTリクエストをリダイレクトするとGETされる?POSTされる? - はこべにっき#]] ([TIME[2009-07-08 20:09:48 +09:00]] 版) [402] [CITE@en-US[Extra CRLF Character Is Added to a POST Request That Is Sent to an HTTP 1.1 Server]] ( ([TIME[2011-05-28 01:14:56 +09:00]] 版)) [403] [CITE[Apache HTTP Server Project]] ( ([TIME[2011-05-28 00:58:55 +09:00]] 版)) [404] [CITE[Apache HTTP Server Project]] ( ([TIME[2011-05-28 00:58:55 +09:00]] 版))