The POST method is used to request that the {1945,2068} destination {2616} origin server accept the entity enclosed in the request as {1945,2068,2616} a new subordinate of {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:

POST 方式は、起源サーバーが要求に囲まれた実体を Request-Line の Request-URI で識別される資源の新しい付随物で処理するデータとして受け入れることを要求するのに使います。 POST は次の機能を覆う統一方式とできるように設計されています。

• {1945,2068} o {2616} - Annotation of existing resources;
• o - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
• o - Providing a block of data, such as the result of submitting a form [3] , to a data-handling process;
• o - 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. {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. {Errata で削除}

POST}] 方式で行われる実際の機能はサーバーにより決定され、 通常 Request-URI に依存します。投稿された実体は、ファイルがそれを含むディレクトリに付随するとか、ニュース記事が投稿されたニュース組に付随するとか、記録がデータベースに藤生するのと同じように、その URI に付随します。

{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 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 {1945} (ok) (OK) or 204 {1945} (no content) (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

;POST が成功したからといって、その実体が起源サーバーで資源として作られたり、生来の参照で接続可能となる必要はありません。つまり、 POST 方式で行われる動作は結果として URI で識別できる資源にならないかもしれません。 この場合、応答が結果を説明する実体を含むか否かによって、 200 (了解) または 204 (無内容) が適切な応答符号です。

If a resource has been created on the origin server, the response {1945} should SHOULD be 201 {1945} (created) (Created) and contain an entity {1945} (preferably of type "text/html") which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

起源サーバーに資源が作られた場合は、応答は 201 (作成せし) とし、 要求の状態を説明して新しい資源を参照する実体と、 Location 頭を含むべきです。

The description of POST was broadened over time, and is not clear.

POST の説明は時間と共に広がり、明確ではありません。

[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.

資源が透過折衝可能であるときには、これはその資源の GET 及び HEAD の処理にのみ影響します。 (この仕様書では) 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.

しかし、 POST 要求は利用者エージェントに2番目の資源に GET 要求を行わせる折衝しない 303 (他を見よ) 応答を返すことが出来ます。 この2番目の応答の方は透過内容折衝を使って適当な最終応答を返すことができます。 次の図はこれを図示しています。

      Server ______ proxy ______ proxy ______ user
      x.org         cache        cache        agent
        < -------------------------------------
        |     POST http://x.org/cgi/submit
        |     <form contents in request body>
        |
        -------------------------------------- >
              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

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.