HTTP/1.1のメソッド
SIPプロトコルは、HTTPをベースに開発したと、RFC3261にもうたわれている。そこで、SIPのルーツを理解するため、今回は、HTTPに規定されているメソッドを調べてみた。
HTTPの最新版であるHTTP/1.1は、RFC2616で規定されている。RFC2616には、「OPTIONS」「GET」「HEAD」「POST」「PUT」「DELETE」「TRACE」「CONNECT」という8つのメソッドが規定されている。それぞれのメリクエストのソッドの概要は以下のとおりである。
メソッドの名前が決められていて、それがリクエストメッセージの最初に書かれるという点は、HTTPとSIPで共通している。Request-URIという言葉も共通で、HTTPをベースに開発といわれている意味が理解できる。ただ、HTTPで規定されている「OPTIONS」メソッドは、SIPにも同じ名前、同じ用途で引き継がれているものの、（用途が違うので当然といえば当然だが）ほとんどのメソッド名は共通してない。
以前、IETFのSIPワーキンググループで、デバックの目的で、受け取ったメッセージ内容をそのままボディ部に載せて発信者に返すというアイデアをだしていた人がいたが、考え方としては、HTTPの「TRACE」メソッドを踏襲したものなのでしょう。（具体的な検討はすすんでないようですが。）IETFでのSIPプロトコルの標準化の動きを見るうえでは、ベースとしているHTTPの歴史は参考になるように思います。
『HTTP/1.1 で規定されるメソッド』
●OPTIONS
サーバやRequest-URIで指定されるリソースで、利用可能なオプション一覧を取得するためのメソッドである。応答をキャッシュに保存してはいけない。
●GET
Request-URIで識別される情報を取り出すためのメソッド。
●HEAD
Request-URIで識別されるエンティティのメタ情報を取得するためのメソッド。応答のメッセージボディが空である点以外は、GETメソッドと同じ動作。
●POST
POSTリクエストのメッセージボディに添付したエンティティを、Request-URIで指定したリソースに従属するものとして受け入れることをサーバに要求するためのメソッド。
●PUT
Request-URIで示される場所に、PUTリクエストに含まれる内容を置くことを要求するためのメソッド。
●DELETE
Request-URIで識別されるリソースを削除することを要求するメソッド。
●TRACE
アプリケーションレイヤでのループバック試験を行うためのメソッド。応答のボディ部には、最終的にサーバに届いたリクエストの内容がそのまま含められる。
●CONNECT
プロキシでの利用のために"CONNECT"というメソッド名が予約されている。
【以下参考：RFC2616（http://www.ietf.org/rfc/rfc2616.txt）より抜粋】
9.2 OPTIONS
The OPTIONS method represents a request for information about the
communication options available on the request/response chain
identified by the Request-URI. This method allows the client to
determine the options and/or requirements associated with a resource,
or the capabilities of a server, without implying a resource action
or initiating a resource retrieval.
Responses to this method are not cacheable.
（中略）
9.3 GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
（中略）
9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
（中略）
9.5 POST
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
（中略）
9.6 PUT
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response. If an existing resource is modified,
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
to indicate successful completion of the request. If the resource
could not be created or modified with the Request-URI, an appropriate
error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases.
（中略）
9.7 DELETE
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot
be guaranteed that the operation has been carried out, even if the
status code returned from the origin server indicates that the action
has been completed successfully. However, the server SHOULD NOT
indicate success unless, at the time the response is given, it
intends to delete the resource or move it to an inaccessible
location.
（中略）
9.8 TRACE
The TRACE method is used to invoke a remote, application-layer loop-
back of the request message. The final recipient of the request
SHOULD reflect the message received back to the client as the
entity-body of a 200 (OK) response. The final recipient is either the
origin server or the first proxy or gateway to receive a Max-Forwards
value of zero (0) in the request (see section 14.31). A TRACE request
MUST NOT include an entity.
（中略）
9.9 CONNECT
This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [44]).
SIPandVoIPトップに戻る
