HTTP
HTTPリクエスト
サーチ…
パラメーター
HTTPメソッド | 目的 |
---|---|
OPTIONS | 指定された要求URIで利用可能な通信オプション(利用可能なメソッドとヘッダー)に関する情報を取得します。 |
GET | 要求URIによって識別されるデータ、または要求URIで使用可能なスクリプトによって生成されたデータを取得します。 |
HEAD | GET と同じですが、サーバーから返されるメッセージ本文はなく、ヘッダーのみです。 |
POST | リクエストURIで指定されたリソースに追加するために、(メッセージ本体で指定された)データブロックをサーバに送信します。フォーム処理に最も一般的に使用されます。 |
PUT | 囲まれた情報を(メッセージ本体に)指定された要求URIの下に新しいリソースまたは更新されたリソースとして格納します。 |
DELETE | 要求URIによって識別されるリソースを削除するか、または削除待ちにする。 |
TRACE | 基本的にechoコマンド:機能している準拠のHTTPサーバーは、200(OK)応答の本体として要求全体を送り返す必要があります。 |
備考
CONNECT
メソッドは、プロキシ・モードとトンネリング・モード(SSLトンネリングなど)を切り替えることができるプロキシで使用するためのメソッド定義仕様によって予約されています。
Telnetを使用して手動で最小限のHTTP要求を送信する
この例では、HTTPはテキストベースのインターネット通信プロトコルであり、基本的なHTTP要求と対応するHTTP応答を示しています。
Telnetを使用して、次のように最小限のHTTP要求をコマンドラインから手動で送信できます。
ポート80のWebサーバ
www.example.org
へのTelnetセッションを開始します。telnet www.example.org 80
Telnetは、サーバーに接続したことを報告します。
Connected to www.example.org. Escape character is '^]'.
GETリクエストのURLパス送信要求ライン入力
/
HTTP 1.1を使用して、GET / HTTP/1.1
必要なURLのホスト名部分を識別するHTTPヘッダーフィールド行を入力します。これはHTTP 1.1で必要です
Host: www.example.org
空白行を入力して要求を完了します。
WebサーバーはTelnetセッションに表示されるHTTP応答を送信します。
完全なセッションは以下の通りです。応答の最初の行はHTTPステータス行で、ステータスコード200と要求テキストが正常に処理されたことを示すステータステキストOKが含まれています。これには、いくつかのHTTPヘッダーフィールド、空白行、およびHTML応答が続きます。
$ telnet www.example.org 80
Trying 2606:2800:220:1:248:1893:25c8:1946...
Connected to www.example.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.example.org
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Thu, 21 Jul 2016 15:56:05 GMT
Etag: "359670651"
Expires: Thu, 28 Jul 2016 15:56:05 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (lga/1318)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is established to be used for illustrative examples in documents. You may use this
domain in examples without prior coordination or asking for permission.</p>
<p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
(簡潔にするために、 style
要素と空白行をHTML応答から削除しました)。
基本要求形式
HTTP 1.1では、最小限のHTTP要求は要求行とHost
ヘッダーで構成されます。
GET /search HTTP/1.1 \r\n
Host: google.com \r\n
\r\n
最初の行の形式は次のとおりです。
Method Request-URI HTTP-Version CRLF
Method
は有効なHTTP Method
なければなりません。 [1] [2]のいずれか :
-
OPTIONS
-
GET
-
HEAD
-
POST
-
PUT
-
DELETE
-
PATCH
-
TRACE
-
CONNECT
Request-URI
は、URIまたはクライアントが要求しているリソースへのパスを示します。次のいずれかになります。
- スキーマ、ホスト、(オプションの)ポートとパスを含む完全修飾URI。または
- パスを指定します。この場合、ホストは
Host
ヘッダーで指定する必要があります
HTTP-Version
は、クライアントが使用しているHTTPプロトコルのバージョンを示します。 HTTP 1.1要求の場合、これは常にHTTP/1.1
なければなりません。
要求行は通常、 \r\n
表される復帰改行フィード対で終わります。
リクエストヘッダフィールド
ヘッダーフィールド(通常は単に「ヘッダー」と呼ばれる)をHTTP要求に追加して、要求に関する追加情報を提供することができます。ヘッダは、そのようなことをサポートするプログラミング言語のメソッドに渡されるパラメータと同様のセマンティクスを持っています。
Host
、 User-Agent
、およびReferer
ヘッダーの要求は次のようになります。
GET /search HTTP/1.1 \r\n
Host: google.com \r\n
User-Agent: Chrome/54.0.2803.1 \r\n
Referer: http://google.com/ \r\n
\r\n
サポートされているHTTP 1.1要求ヘッダーの完全なリストは、仕様書に記載されています 。最も一般的なのは次のとおりです。
-
Host
- リクエストURLのホスト名部分(HTTP / 1.1で必須) -
User-Agent
- 要求しているユーザエージェントを表す文字列。 -
Referer
- ここでクライアントが参照されたURI。そして -
If-Modified-Since
- サーバーがリソースが変更されたかどうかを判断し、クライアントがキャッシュされていないコピーを使用できることを示すためにサーバーが使用できる日付を指定します。
ヘッダーは、 Name: Value CRLF
として作成する必要があります。 Name
は、 User-Agent
などのヘッダー名です。 Value
はそれに割り当てられたデータであり、行はCRLFで終わる必要があります。ヘッダ名は大文字と小文字を区別しないとのみ、文字、数字や文字を使用することができます!#$%&'*+-.^_`|~
(RFC7230セクション3.2.6フィールド値成分 )。
Referer
ヘッダーフィールド名はRFC1945で誤って導入された ' referrer 'のタイプミスです。
メッセージ本文
一部のHTTPリクエストにはメッセージ本文が含まれている場合があります。これは、サーバーが要求を処理するために使用する追加データです。メッセージ本体は、サーバーがリソースに適用する新しいデータを提供するために、POSTまたはPATCHおよびPUT要求で最もよく使用されます。
メッセージ本文を含む要求は、長さを常にContent-Length
ヘッダーとともにバイト単位で含める必要があります。
すべてのヘッダーの後にメッセージ本体が含まれ、 CRLFが2つ含まれます。本文を含むPUTリクエストの例は、次のようになります。
PUT /files/129742 HTTP/1.1\r\n
Host: example.com\r\n
User-Agent: Chrome/54.0.2803.1\r\n
Content-Length: 202\r\n
\r\n
This is a message body. All content in this message body should be stored under the
/files/129742 path, as specified by the PUT specification. The message body does
not have to be terminated with CRLF.
HEAD
要求とTRACE
要求にはメッセージ本文を含めないでください。