Http-quick-guide

HTTP-概要

ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーメディア情報システム用のアプリケーションレベルのプロトコルです。 これは、World Wide Webのデータ通信の基盤です（つまり、 インターネット）1990年以降。 HTTPは、リクエストメソッド、エラーコード、およびヘッダーの拡張機能を使用するだけでなく、他の目的にも使用できる汎用のステートレスプロトコルです。

基本的に、HTTPはTCP/IPベースの通信プロトコルであり、World Wide Web上でデータ（HTMLファイル、画像ファイル、クエリ結果など）を配信するために使用されます。 デフォルトのポートはTCP 80ですが、他のポートも使用できます。 コンピューターが相互に通信するための標準化された方法を提供します。 HTTP仕様では、クライアントの要求データを構築してサーバーに送信する方法、およびサーバーがこれらの要求に応答する方法を指定します。

基本的な機能

HTTPをシンプルだが強力なプロトコルにする3つの基本的な機能があります。

• * HTTPはコネクションレス：* HTTPクライアント、つまりブラウザーはHTTPリクエストを開始し、リクエストが行われた後、クライアントはレスポンスを待ちます。 サーバーは要求を処理し、応答を送り返します。その後、クライアントは接続を切断します。 そのため、クライアントとサーバーは、現在の要求と応答の間だけお互いを認識します。 クライアントとサーバーがお互いに新しいような新しい接続で、さらに要求が行われます。
• * HTTPはメディアに依存しません：*クライアントとサーバーの両方がデータコンテンツの処理方法を知っている限り、HTTPであらゆるタイプのデータを送信できます。 クライアントだけでなくサーバーも、適切なMIMEタイプを使用してコンテンツタイプを指定する必要があります。
• * HTTPはステートレスです：*前述のように、HTTPはコネクションレスであり、HTTPがステートレスプロトコルであることの直接的な結果です。 サーバーとクライアントは、現在の要求の間のみ互いに​​認識します。 その後、二人はお互いを忘れます。 このプロトコルの性質により、クライアントもブラウザも、Webページ全体の異なるリクエスト間で情報を保持できません。

'_HTTP/1.0は、要求/応答の交換ごとに新しい接続を使用します。HTTP/1.1接続は、1つ以上の要求/応答の交換に使用できます。_

基本的なアーキテクチャ

次の図は、Webアプリケーションの非常に基本的なアーキテクチャを示し、HTTPの位置を示しています。

HTTPアーキテクチャ

HTTPプロトコルは、Webブラウザ、ロボット、検索エンジンなどのクライアント/サーバーベースのアーキテクチャに基づく要求/応答プロトコルです。 HTTPクライアントのように機能し、Webサーバーはサーバーとして機能します。

クライアント

HTTPクライアントは、要求メソッド、URI、およびプロトコルバージョンの形式でサーバーに要求を送信し、TCP/IP接続を介して、要求修飾子、クライアント情報、および可能性のある本文コンテンツを含むMIMEのようなメッセージが続きます。

サーバ

HTTPサーバーは、メッセージのプロトコルバージョンと成功またはエラーコードを含むステータス行で応答し、その後にサーバー情報、エンティティメタ情報、およびエンティティ本体コンテンツを含むMIMEのようなメッセージが続きます。

HTTP-パラメーター

この章では、いくつかの重要なHTTPプロトコルパラメーターとその構文が通信で使用される方法をリストします。 たとえば、日付の形式、URLの形式など。 これは、HTTPクライアントまたはサーバープログラムの作成中に、要求および応答メッセージを作成するのに役立ちます。 HTTPリクエストとレスポンスのメッセージ構造を学習しながら、以降の章でこれらのパラメーターの完全な使用法を確認します。

HTTPバージョン

HTTPは、プロトコルのバージョンを示すために <major>。<minor> 番号付けスキームを使用します。 HTTPメッセージのバージョンは、最初の行のHTTP-Versionフィールドで示されます。 HTTPバージョン番号を指定する一般的な構文は次のとおりです。

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

例

HTTP/1.0

or

HTTP/1.1

統一リソース識別子

Uniform Resource Identifiers（URI）は、名前、場所などを含む単純にフォーマットされた大文字と小文字を区別しない文字列です。 Webサイト、Webサービスなどのリソースを識別するため HTTPに使用されるURIの一般的な構文は次のとおりです。

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

ここで、 port が空であるか指定されていない場合、HTTPに対してポート80が想定され、空の abs_path は「/」の abs_path と同等です。 reserved および unsafe セットの文字以外の文字は、 ""％ "HEX HEX"エンコーディングと同等です。

例

次の3つのURIは同等です。

http://abc.com:80/~smith/homel
http://ABC.com/%7Esmith/homel
http://ABC.com:/%7esmith/homel

日付/時刻形式

すべてのHTTP日付/時刻スタンプは、例外なくグリニッジ標準時（GMT）で表されなければなりません。 HTTPアプリケーションは、日付/時刻スタンプの次の3つの表現のいずれかを使用できます。

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

キャラクターセット

文字セットを使用して、クライアントが好む文字セットを指定します。 複数の文字セットをコンマで区切ってリストできます。 値が指定されていない場合、デフォルトはUS-ASCIIです。

例

有効な文字セットは次のとおりです。

US-ASCII

or

ISO-8859-1

or

ISO-8859-7

コンテンツエンコーディング

コンテンツのエンコード値は、ネットワークを介して渡す前にエンコードアルゴリズムを使用してコンテンツをエンコードしたことを示します。 コンテンツコーディングは主に、IDを失うことなくドキュメントを圧縮したり、便利に変換したりするために使用されます。

すべてのコンテンツコーディング値は大文字と小文字を区別しません。 HTTP/1.1は、Accept-EncodingおよびContent-Encodingヘッダーフィールドでcontent-coding値を使用します。これについては、以降の章で説明します。

例

有効なエンコードスキームは次のとおりです。

Accept-encoding: gzip

or

Accept-encoding: compress

or

Accept-encoding: deflate

メディアの種類

HTTPは、 Content-Type および Accept ヘッダーフィールドでインターネットメディアタイプを使用して、オープンで拡張可能なデータタイピングとタイプネゴシエーションを提供します。 すべてのメディアタイプの値は、Internet Assigned Number Authority（IANA）に登録されています。 メディアタイプを指定する一般的な構文は次のとおりです。

media-type     = type "/" subtype *( ";" parameter )

タイプ、サブタイプ、およびパラメーターの属性名は大文字と小文字が区別されません。

例

Accept: image/gif

言語タグ

HTTPは、 Accept-Language および Content-Language フィールド内で言語タグを使用します。 言語タグは、1つまたは複数の部分で構成されます：プライマリ言語タグと、空のサブタグのシリーズ：

language-tag  = primary-tag *( "-" subtag )

タグ内で空白を使用することはできません。すべてのタグでは大文字と小文字が区別されません。

例

タグの例：

en, en-US, en-cockney, i-cherokee, x-pig-latin

ここで、2文字のprimary-tagはISO-639言語の略語であり、2文字の最初のサブタグはISO-3166国コードです。

HTTP-メッセージ

HTTPは、クライアント/サーバーアーキテクチャモデルと、信頼性の高いTCP/IP接続でメッセージを交換することで動作するステートレスな要求/応答プロトコルに基づいています。

HTTP「クライアント」は、1つ以上のHTTP要求メッセージを送信する目的でサーバーへの接続を確立するプログラム（Webブラウザーまたはその他のクライアント）です。 HTTP「サーバー」はプログラムです（一般的には、Apache WebサーバーやインターネットインフォメーションサービスIISなどのWebサーバーです。 ）HTTP応答メッセージを送信してHTTP要求を処理するために接続を受け入れます。

HTTPは、Uniform Resource Identifier（URI）を使用して、特定のリソースを識別し、接続を確立します。 接続が確立されると、* HTTPメッセージ*は、インターネットメール[RFC5322]および多目的インターネットメール拡張機能（MIME）[RFC2045]で使用されるものと同様の形式で渡されます。 これらのメッセージには、クライアントからサーバーへの*要求*およびサーバーからクライアントへの*応答*が含まれます。形式は次のとおりです。

 HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

HTTP要求およびHTTP応答は、RFC 822の一般的なメッセージ形式を使用して、必要なデータを転送します。 この一般的なメッセージ形式は、次の4つの項目で構成されています。

• スタートライン
• CRLFが後に続く0個以上のヘッダーフィールド
• 空の行（CRLFの前に何もない行） ヘッダーフィールドの終わりを示す
• オプションでメッセージ本文

次のセクションでは、HTTPメッセージで使用される各エンティティについて説明します。

メッセージの開始行

スタートラインには次の一般的な構文があります。

start-line = Request-Line | Status-Line

HTTPリクエストメッセージとHTTPレスポンスメッセージについてそれぞれ説明しながら、Request-LineとStatus-Lineについて説明します。 とりあえず、リクエストとレスポンスの場合の開始行の例を見てみましょう。

GET/hello HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

ヘッダーフィールド

HTTPヘッダーフィールドは、要求または応答、またはメッセージ本文で送信されるオブジェクトに関する必要な情報を提供します。 HTTPメッセージヘッダーには4つのタイプがあります。

• * General-header：*これらのヘッダーフィールドには、要求メッセージと応答メッセージの両方に一般的な適用性があります。
• * Request-header：*これらのヘッダーフィールドは、リクエストメッセージにのみ適用可能です。
• * Response-header：*これらのヘッダーフィールドは、応答メッセージにのみ適用可能です。
• * Entity-header：*これらのヘッダーフィールドは、エンティティ本体に関するメタ情報、または本体が存在しない場合はリクエストによって識別されるリソースに関するメタ情報を定義します。

上記のヘッダーはすべて同じ一般的な形式に従い、ヘッダーフィールドはそれぞれ、名前の後にコロン（：）とフィールド値で構成され、次のようになります。

message-header = field-name ":" [ field-value ]

以下は、さまざまなヘッダーフィールドの例です。

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

メッセージ本文

HTTPメッセージのメッセージ本文部分はオプションですが、使用可能な場合は、要求または応答に関連付けられたエンティティ本体を運ぶために使用されます。 エンティティボディが関連付けられている場合、通常、 Content-Type および Content-Length ヘッダー行は、関連付けられているボディの性質を指定します。

メッセージ本文は、実際のHTTP要求データ（フォームデータやアップロードなどを含む）およびサーバーからのHTTP応答データ（ファイル、画像などを含む）を運ぶものです。 以下に、メッセージ本文の簡単なコンテンツを示します。

<html>
   <body>

      <h1>Hello, World!</h1>

   </body>
</html>

次の2つの章では、上記で説明した概念を利用して、HTTP要求とHTTP応答を準備します。

HTTP-リクエスト

HTTPクライアントは、次の形式を含む要求メッセージの形式でサーバーにHTTP要求を送信します。

• リクエストライン
• CRLFが後に続く0個以上のヘッダー（一般|リクエスト|エンティティ）フィールド
• 空の行（CRLFの前に何もない行） ヘッダーフィールドの終わりを示す
• オプションでメッセージ本文

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Request-Lineに記載されている各部分について説明しましょう。

リクエスト方法

リクエスト method は、指定された Request-URI で識別されるリソースで実行されるメソッドを示します。 メソッドは大文字と小文字を区別し、常に大文字で表記する必要があります。 次の表に、HTTP/1.1でサポートされているすべてのメソッドを示します。

S.N.	Method and Description
1	GET GETメソッドは、特定のURIを使用して特定のサーバーから情報を取得するために使用されます。 GETを使用するリクエストは、データを取得するだけで、データに他の影響を与えません。
2	HEAD GETと同じですが、ステータス行とヘッダーセクションのみを転送します。
3	POST POSTリクエストは、顧客情報、ファイルのアップロードなどのデータをサーバーに送信するために使用されます。 HTMLフォームを使用します。
4	PUT ターゲットリソースの現在のすべての表現を、アップロードされたコンテンツで置き換えます。
5	DELETE URIで指定されたターゲットリソースの現在の表現をすべて削除します。
6	CONNECT 特定のURIで識別されるサーバーへのトンネルを確立します。
7	OPTIONS ターゲットリソースの通信オプションを説明します。
8	TRACE ターゲットリソースへのパスとともにメッセージループバックテストを実行します。

リクエストURI

Request-URIはUniform Resource Identifierであり、リクエストを適用するリソースを識別します。 URIを指定するために最も一般的に使用されるフォームは次のとおりです。

Request-URI = "*" | absoluteURI | abs_path | authority

S.N.	Method and Description
1	The asterisk * is used when an HTTP request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. For example: オプション *HTTP/1.1
2	The absoluteURI is used when an HTTP request is being made to a proxy. The proxy is requested to forward the request or service from a valid cache, and return the response. For example: GET http://www.w3.org/pub/WWW/TheProjectl HTTP/1.1*
3	The most common form of Request-URI is that used to identify a resource on an origin server or gateway. For example, a client wishing to retrieve a resource directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the following lines: GET/pub/WWW/TheProjectl HTTP/1.1* ホスト：www.w3.org * 絶対パスを空にすることはできません。元のURIに何も存在しない場合、「/」（サーバールート）として指定する必要があります。

リクエストヘッダーフィールド

HTTPヘッダーフィールドを学習するときは、別の章でGeneral-headerとEntity-headerを学習します。 とりあえず、Requestヘッダーフィールドを確認しましょう。

リクエストヘッダーフィールドを使用すると、クライアントはリクエストに関する追加情報とクライアント自体に関する情報をサーバーに渡すことができます。 これらのフィールドはリクエスト修飾子として機能します。要件に基づいて使用できる重要なリクエストヘッダーフィールドのリストを次に示します。

• 受け入れ文字セット
• 受け入れエンコード
• 受け入れ言語
• 承認
• 期待する
• From
• Host
• 一致する場合
• If-Modified-Since
• If-None-Match
• If範囲
• 未修正の場合
• マックスフォワード
• プロキシ承認
• 範囲
• リファラー
• TE
• ユーザーエージェント

独自のカスタムクライアントおよびWebサーバーを作成する場合に備えて、カスタムフィールドを導入できます。

リクエストメッセージの例

それをまとめて、finddevguides.comで実行されているWebサーバーから hello ページをフェッチするHTTPリクエストを作成しましょう

GET/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

ここでは、サーバーからプレーンHTMLページを取得しているため、サーバーに要求データを送信していません。 接続は汎用ヘッダーであり、残りのヘッダーは要求ヘッダーです。 次の例は、要求メッセージ本文を使用してフォームデータをサーバーに送信する方法を示しています。

POST/cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

ここでは、渡されたデータを処理するために指定されたURL _/cgi-bin/process.cgi_が使用され、それに応じて応答が返されます。 ここで、 content-type は、渡されたデータが単純なWebフォームデータであり、 length がメッセージ本文に入れられたデータの実際の長さであることをサーバーに伝えます。 次の例は、プレーンXMLをWebサーバーに渡す方法を示しています。

POST/cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

HTTP-応答

要求メッセージを受信して​​解釈した後、サーバーはHTTP応答メッセージで応答します。

• ステータスライン
• CRLFが後に続く0個以上のヘッダー（一般|応答|エンティティ）フィールド
• 空の行（CRLFの前に何もない行） ヘッダーフィールドの終わりを示す *オプションでメッセージ本文

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTPバージョン

HTTPバージョン1.1をサポートするサーバーは、次のバージョン情報を返します。

HTTP-Version = HTTP/1.1

状態コード

Status-Codeエレメントは3桁の整数です。Status-Codeの最初の桁は応答のクラスを定義し、最後の2桁には分類の役割はありません。 最初の桁には5つの値があります。

S.N.	Code and Description
1	1xx: Informational* 要求が受信され、プロセスが継続していることを意味します。
2	2xx: Success アクションが正常に受信、理解、および受け入れられたことを意味します。
3	3xx: Redirection これは、要求を完了するためにさらにアクションを実行する必要があることを意味します。
4	4xx: Client Error これは、リクエストに誤った構文が含まれているか、リクエストを実行できないことを意味します。
5	5xx: Server Error サーバーが明らかに有効な要求を実行できなかったことを意味します。

HTTPステータスコードは拡張可能であり、HTTPアプリケーションはすべての登録済みステータスコードの意味を理解する必要はありません。 すべてのステータスコードのリストは、参照用に別の章に記載されています。

応答ヘッダーフィールド

HTTPヘッダーフィールドを学習するときは、別の章でGeneral-headerとEntity-headerを学習します。 ここでは、Responseヘッダーフィールドが何であるかを確認しましょう。

応答ヘッダーフィールドにより、サーバーは、Status-Lineに配置できない応答に関する追加情報を渡すことができます。 これらのヘッダーフィールドは、サーバーに関する情報と、Request-URIで識別されるリソースへのさらなるアクセスに関する情報を提供します。

• 受諾範囲
• Age
• ETag
• ロケーション
• プロキシ認証
• 再試行後
• サーバ
• Vary
• WWW-認証

独自のカスタムWebクライアントおよびサーバーを作成する場合に備えて、カスタムフィールドを導入できます。

応答メッセージの例

それをまとめて、finddevguides.comで実行されているWebサーバーから hello ページをフェッチする要求のHTTP応答を作成します。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

次の例は、Webサーバーが要求されたページを見つけられなかった場合にエラー状態を表示するHTTP応答メッセージを示しています。

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL/tl was not found on this server.</p>
</body>
</html>

以下は、Webサーバーが指定されたHTTP要求で誤ったHTTPバージョンを検出した場合のエラー状態を示すHTTP応答メッセージの例です。

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.</p>
   <p>The request line contained invalid characters following the protocol string.</p>
</body>
</html>

HTTP-メソッド

HTTP/1.1の共通メソッドのセットを以下に定義し、このセットは要件に基づいて拡張できます。 これらのメソッド名は大文字と小文字が区別され、大文字で使用する必要があります。

S.N.	Method and Description
1	GET GETメソッドは、特定のURIを使用して特定のサーバーから情報を取得するために使用されます。 GETを使用するリクエストは、データを取得するだけで、データに他の影響を与えません。
2	HEAD GETと同じですが、ステータス行とヘッダーセクションのみを転送します。
3	POST POSTリクエストは、顧客情報、ファイルのアップロードなどのデータをサーバーに送信するために使用されます。 HTMLフォームを使用します。
4	PUT ターゲットリソースの現在のすべての表現を、アップロードされたコンテンツで置き換えます。
5	DELETE URIで指定されたターゲットリソースの現在の表現をすべて削除します。
6	CONNECT 特定のURIで識別されるサーバーへのトンネルを確立します。
7	OPTIONS ターゲットリソースの通信オプションについて説明します。
8	TRACE ターゲットリソースへのパスに沿ってメッセージループバックテストを実行します。

GETメソッド

GET要求は、要求のURL部分にパラメーターを指定することにより、Webサーバーからデータを取得します。 これは、ドキュメントの取得に使用される主な方法です。 次の例では、GETメソッドを使用してhelloをフェッチします。

GET/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

上記のGET要求に対するサーバーの応答は次のとおりです。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HEADメソッド

HEADメソッドは機能的にはGETと似ていますが、サーバーが応答行とヘッダーで応答しますが、エンティティ本体はありません。 次の例では、HEADメソッドを使用してhelloに関するヘッダー情報をフェッチします。

HEAD/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

上記のGET要求に対するサーバーの応答は次のとおりです。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

ここで、サーバーはヘッダーの後にデータを送信しないことに注意してください。

POSTメソッド

POSTメソッドは、ファイルの更新、フォームデータなどのデータをサーバーに送信するときに使用されます。 次の例では、POSTメソッドを使用してフォームデータをサーバーに送信します。フォームデータは、process.cgiによって処理され、最終的に応答が返されます。

POST/cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

サーバー側のスクリプトprocess.cgiは、渡されたデータを処理し、次の応答を送信します。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

PUTメソッド

PUTメソッドは、指定されたURLで指定された場所に含まれるエンティティ本体を格納するようサーバーに要求するために使用されます。 次の例では、指定されたエンティティ本体をサーバーのルートにある hello に保存するようサーバーに要求します。

PUT/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

サーバーは指定されたエンティティ本体を hello ファイルに保存し、次の応答をクライアントに送信します。

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

DELETEメソッド

DELETEメソッドは、指定されたURLで指定された場所にあるファイルを削除するようサーバーに要求するために使用されます。 次の例では、サーバーに、サーバーのルートにある特定のファイル hello を削除するように要求します。

DELETE/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Connection: Keep-Alive

サーバーは上記のファイル hello を削除し、次の応答をクライアントに送信します。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

CONNECTメソッド

クライアントはCONNECTメソッドを使用して、HTTP経由でWebサーバーへのネットワーク接続を確立します。 次の例では、ホストfinddevguides.comで実行されているWebサーバーとの接続を要求します。

CONNECT www.finddevguides.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

サーバーとの接続が確立され、次の応答がクライアントに返されます。

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

OPTIONSメソッド

OPTIONSメソッドは、WebサーバーでサポートされているHTTPメソッドやその他のオプションを見つけるためにクライアントによって使用されます。 クライアントは、OPTIONSメソッドのURL、またはサーバー全体を参照するアスタリスク（*）を指定できます。 次の例は、finddevguides.comで実行されているWebサーバーでサポートされているメソッドのリストを要求します。

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

サーバーは、サーバーの現在の構成に基づいて、次のような情報を送信します。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

TRACEメソッド

TRACEメソッドは、HTTP要求の内容をリクエスターにエコーバックするために使用されます。これは、開発時のデバッグ目的に使用できます。 次の例は、TRACEメソッドの使用法を示しています。

TRACE/HTTP/1.1
Host: www.finddevguides.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

サーバーは、上記のリクエストに応じて次のメッセージを送信します。

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE/HTTP/1.1
Host: www.finddevguides.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

HTTP-ステータスコード

サーバー応答のStatus-Code要素は3桁の整数です。Status-Codeの最初の桁は応答のクラスを定義し、最後の2桁には分類の役割はありません。 最初の桁には5つの値があります。

S.N.	Code and Description
1	1xx: Informational 要求が受信され、プロセスが継続していることを意味します。
2	2xx: Success アクションが正常に受信、理解、および受け入れられたことを意味します。
3	3xx: Redirection これは、要求を完了するためにさらにアクションを実行する必要があることを意味します。
4	4xx: Client Error これは、リクエストに誤った構文が含まれているか、リクエストを実行できないことを意味します。
5	5xx: Server Error サーバーが明らかに有効な要求を実行できなかったことを意味します。

HTTPステータスコードは拡張可能であり、HTTPアプリケーションは登録されているすべてのステータスコードの意味を理解する必要はありません。 以下に、すべてのステータスコードのリストを示します。

1xx：情報

Message	Description
100 Continue	Only a part of the request has been received by the server, but as long as it has not been rejected, the client should continue with the request.
101 Switching Protocols	The server switches protocol.

2xx：成功

Message	Description
200 OK	The request is OK.
201 Created	The request is complete, and a new resource is created .
202 Accepted	The request is accepted for processing, but the processing is not complete.
203 Non-authoritative Information	The information in the entity header is from a local or third-party copy, not from the original server.
204 No Content	A status code and a header are given in the response, but there is no entity-body in the reply.
205 Reset Content	The browser should clear the form used for this transaction for additional input.
206 Partial Content	The server is returning partial data of the size requested. Used in response to a request specifying a Range header. The server must specify the range included in the response with the Content-Range header.

3xx：リダイレクト

Message	Description
300 Multiple Choices	A link list. The user can select a link and go to that location. Maximum five addresses  .
301 Moved Permanently	The requested page has moved to a new url .
302 Found	The requested page has moved temporarily to a new url .
303 See Other	The requested page can be found under a different url .
304 Not Modified	This is the response code to an If-Modified-Since or If-None-Match header, where the URL has not been modified since the specified date.
305 Use Proxy	The requested URL must be accessed through the proxy mentioned in the Location header.
306 Unused	This code was used in a previous version. It is no longer used, but the code is reserved.
307 Temporary Redirect	The requested page has moved temporarily to a new url.

4xx：クライアントエラー

Message	Description
400 Bad Request	The server did not understand the request.
401 Unauthorized	The requested page needs a username and a password.
402 Payment Required	You can not use this code yet.
403 Forbidden	Access is forbidden to the requested page.
404 Not Found	The server can not find the requested page.
405 Method Not Allowed	The method specified in the request is not allowed.
406 Not Acceptable	The server can only generate a response that is not accepted by the client.
407 Proxy Authentication Required	You must authenticate with a proxy server before this request can be served.
408 Request Timeout	The request took longer than the server was prepared to wait.
409 Conflict	The request could not be completed because of a conflict.
410 Gone	The requested page is no longer available .
411 Length Required	The "Content-Length" is not defined. The server will not accept the request without it .
412 Precondition Failed	The pre condition given in the request evaluated to false by the server.
413 Request Entity Too Large	The server will not accept the request, because the request entity is too large.
414 Request-url Too Long	The server will not accept the request, because the url is too long. Occurs when you convert a "post" request to a "get" request with a long query information .
415 Unsupported Media Type	The server will not accept the request, because the mediatype is not supported .
416 Requested Range Not Satisfiable	The requested byte range is not available and is out of bounds.
417 Expectation Failed	The expectation given in an Expect request-header field could not be met by this server.

5xx：サーバーエラー

Message	Description
500 Internal Server Error	The request was not completed. The server met an unexpected condition.
501 Not Implemented	The request was not completed. The server did not support the functionality required.
502 Bad Gateway	The request was not completed. The server received an invalid response from the upstream server.
503 Service Unavailable	The request was not completed. The server is temporarily overloading or down.
504 Gateway Timeout	The gateway has timed out.
505 HTTP Version Not Supported	The server does not support the "http protocol" version.

HTTP-ヘッダーフィールド

HTTPヘッダーフィールドは、要求または応答、またはメッセージ本文で送信されるオブジェクトに関する必要な情報を提供します。 HTTPメッセージヘッダーには4つのタイプがあります。

• * General-header：*これらのヘッダーフィールドには、要求メッセージと応答メッセージの両方に一般的な適用性があります。
• * Client Request-header：*これらのヘッダーフィールドは、リクエストメッセージにのみ適用可能です。
• * Server Response-header：*これらのヘッダーフィールドは、応答メッセージにのみ適用可能です。
• * Entity-header：*これらのヘッダーフィールドは、エンティティ本体に関するメタ情報、または本体が存在しない場合はリクエストによって識別されるリソースに関するメタ情報を定義します。

一般的なヘッダー

キャッシュ制御

Cache-Control general-headerフィールドは、すべてのキャッシングシステムが従わなければならないディレクティブを指定するために使用されます。 構文は次のとおりです。

Cache-Control : cache-request-directive|cache-response-directive

HTTPクライアントまたはサーバーは、 Cache-control 一般ヘッダーを使用して、キャッシュのパラメーターを指定したり、キャッシュから特定の種類のドキュメントを要求したりできます。 キャッシングディレクティブは、コンマ区切りリストで指定されます。 例えば：

Cache-control: no-cache

次の表に、クライアントがHTTP要求で使用できる重要なキャッシュ要求ディレクティブを示します。

S.N.	Cache Request Directive and Description
1	no-cache キャッシュは、元のサーバーとの再検証が成功しない限り、後続の要求を満たすために応答を使用してはなりません。
2	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
3	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
4	max-stale [ = seconds ] 有効期限を超えた応答をクライアントが受け入れようとしていることを示します。 秒が指定されている場合、その時間以上に期限切れになってはいけません。
5	min-fresh = seconds クライアントが、フレッシュネスライフタイムが現在の経過時間に秒単位で指定された時間を足したものよりも小さくない応答を受け入れる意思があることを示します。
6	no-transform エンティティ本体を変換しません。
7	only-if-cached 新しいデータを取得しません。 キャッシュは、ドキュメントがキャッシュ内にある場合にのみドキュメントを送信でき、新しいコピーが存在するかどうかを確認するために配信元サーバーに接続しないでください。

サーバーがHTTP応答で使用できる次の重要なキャッシュ応答ディレクティブ：

S.N.	Cache Response Directive and Description
1	public 応答が任意のキャッシュによってキャッシュされる可能性があることを示します。
2	private 応答メッセージのすべてまたは一部が単一のユーザー向けであり、共有キャッシュによってキャッシュされてはならないことを示します。
3	no-cache キャッシュは、元のサーバーで正常に再検証されない限り、後続の要求を満たすために応答を使用してはなりません。
4	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
5	no-transform エンティティ本体を変換しません。
6	must-revalidate キャッシュは、使用する前に古いドキュメントのステータスを確認する必要があり、期限切れのドキュメントは使用しないでください。
7	proxy-revalidate proxy-revalidateディレクティブは、非共有ユーザーエージェントキャッシュに適用されないことを除いて、must-revalidateディレクティブと同じ意味を持ちます。
8	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
9	s-maxage = seconds このディレクティブで指定された最大年齢は、max-ageディレクティブまたはExpiresヘッダーで指定された最大年齢を上書きします。 s-maxageディレクティブは、プライベートキャッシュによって常に無視されます。

接続

Connection general-headerフィールドを使用すると、送信者はその特定の接続に必要なオプションを指定でき、プロキシはそれ以上の接続で通信することはできません。 接続ヘッダーを使用するための簡単な構文は次のとおりです。

Connection : "Connection"

HTTP/1.1は、送信者が「完了」接続オプションを定義して、応答の完了後に接続が閉じられることを通知します。 例えば：

Connection: close

デフォルトでは、HTTP 1.1は永続的な接続を使用します。この場合、接続はトランザクション後に自動的に閉じられません。 一方、HTTP 1.0には、デフォルトでは永続的な接続がありません。 1.0クライアントが永続的な接続を使用する場合、次のように keep-alive パラメーターを使用します。

Connection: keep-alive

Date

すべてのHTTP日付/時刻スタンプは、例外なくグリニッジ標準時（GMT）で表されなければなりません。 HTTPアプリケーションは、日付/時刻スタンプの次の3つの表現のいずれかを使用できます。

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

ここでは、最初の形式が最も優先されます。

プラグマ

Pragma general-headerフィールドは、要求/応答チェーンに沿った受信者に適用される可能性のある実装固有のディレクティブを含めるために使用されます。 例えば：

Pragma: no-cache

HTTP/1.0で定義されている唯一のディレクティブはno-cacheディレクティブであり、下位互換性のためにHTTP 1.1で維持されています。 将来、新しいプラグマディレクティブは定義されません。

トレーラー

Trailer一般フィールド値は、ヘッダーフィールドの指定されたセットが、チャンク転送コーディングでエンコードされたメッセージのトレーラに存在することを示します。 Trailerヘッダーフィールドの構文は次のとおりです。

Trailer : field-name

Trailerヘッダーフィールドにリストされるメッセージヘッダーフィールドには、次のヘッダーフィールドを含めることはできません。

• 転送エンコード
• コンテンツ長
• トレーラー

転送エンコード

Transfer-Encoding general-headerフィールドは、送信者と受信者の間で安全に転送するために、メッセージ本文に適用された変換のタイプを示します。 transfer-encodingはエンティティ本体ではなくメッセージのプロパティであるため、これはcontent-encodingとは異なります。 Transfer-Encodingヘッダーフィールドの構文は次のとおりです。

Transfer-Encoding: chunked

すべての転送コーディング値は大文字と小文字を区別しません。

アップグレード

_Upgrade_ジェネラルヘッダーを使用すると、クライアントは、サポートする追加の通信プロトコルを指定し、サーバーがプロトコルの切り替えに適していると判断した場合に使用することを指定できます。 例えば：

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Upgradeヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの移行のためのシンプルなメカニズムを提供することを目的としています。

Via

Via general-headerは、中間プロトコルと受信者を示すためにゲートウェイとプロキシによって使用される必要があります。 たとえば、HTTP/1.0ユーザーエージェントから「fred」というコード名の内部プロキシにリクエストメッセージを送信できます。このプロキシは、HTTP/1.1を使用してnowhere.comのパブリックプロキシにリクエストを転送します。 www.ics.uci.eduのオリジンサーバーに転送します。 www.ics.uci.eduが受信したリクエストには、次のViaヘッダーフィールドが含まれます。

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Upgradeヘッダーフィールドは、HTTP/1.1から他の互換性のないプロトコルへの移行のためのシンプルなメカニズムを提供することを目的としています。

警告

Warning general-headerは、メッセージに反映されない可能性のあるメッセージのステータスまたは変換に関する追加情報を伝えるために使用されます。 応答には、複数の警告ヘッダーが含まれる場合があります。

Warning : warn-code SP warn-agent SP warn-text SP warn-date

クライアントリクエストヘッダー

受け入れる

Accept request-headerフィールドを使用して、応答に受け入れられる特定のメディアタイプを指定できます。 一般的な構文は次のとおりです。

Accept: type/subtype [q=qvalue]

複数のメディアタイプをカンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールの受け入れタイプの許容品質レベルを表します。 以下はその例です。

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

これは text/html および text/xc として解釈され、優先されるメディアタイプですが、存在しない場合は text/x-dvi エンティティを送信し、存在しない場合は送信します text/plain エンティティ。

受け入れ文字セット

Accept-Charset request-headerフィールドを使用して、応答に受け入れられる文字セットを示すことができます。 一般的な構文は次のとおりです。

Accept-Charset: character_set [q=qvalue]

複数の文字セットをコンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールでの非優先文字セットの許容品質レベルを表します。 以下はその例です。

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

*Accept-Charset* フィールドに存在する特別な値「*」はすべての文字セットに一致し、 *Accept-Charset* ヘッダーが存在しない場合、デフォルトでは任意の文字セットが受け入れられます。

受け入れエンコード

Accept-Encoding request-headerフィールドはAcceptに似ていますが、応答で受け入れられるコンテンツコーディングを制限します。 一般的な構文は次のとおりです。

Accept-Encoding: encoding types

例は次のとおりです。

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

受け入れ言語

Accept-Language request-headerフィールドはAcceptに似ていますが、リクエストへの応答として優先される自然言語のセットを制限します。 一般的な構文は次のとおりです。

Accept-Language: language [q=qvalue]

複数の言語をコンマで区切ってリストできます。オプションのqvalueは、0〜1のスケールでの非優先言語の許容品質レベルを表します。 以下はその例です。

Accept-Language: da, en-gb;q=0.8, en;q=0.7

承認

Authorization request-headerフィールド値は、要求されているリソースのレルムのユーザーエージェントの認証情報を含む資格情報で構成されます。 一般的な構文は次のとおりです。

Authorization : credentials

HTTP/1.0仕様では、BASIC認可スキームが定義されています。認可パラメータは、base 64でエンコードされた username：password の文字列です。 以下はその例です。

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

デコードされる値は guest：guest123 です。 guest はユーザーID、 guest123 はパスワードです。

クッキー

Cookie request-headerフィールドの値には、そのURLに保存されている情報の名前と値のペアが含まれています。 一般的な構文は次のとおりです。

Cookie: name=value

次のように、セミコロンで区切って複数のCookieを指定できます。

Cookie: name1=value1;name2=value2;name3=value3

期待する

Expect request-headerフィールドは、クライアントがサーバービヘイビアーの特定のセットを必要とすることを示すために使用されます。 一般的な構文は次のとおりです。

Expect : 100-continue | expectation-extension

サーバーが、サポートしていないExpectation-Extensionを含むExpectフィールドを含む要求を受信した場合、417（Expectation Failed）ステータスで応答する必要があります。

From

From request-headerフィールドには、要求元のユーザーエージェントを制御する人間のユーザーのインターネット電子メールアドレスが含まれています。 次に簡単な例を示します。

From: [email protected]

このヘッダーフィールドは、ロギングの目的で、無効または不要なリクエストのソースを識別する手段として使用できます。

Host

Host request-headerフィールドは、要求されているリソースのインターネットホストとポート番号を指定するために使用されます。 一般的な構文は次のとおりです。

Host : "Host" ":" host [ ":" port ] ;

末尾のポート情報のない host は、デフォルトのポートである80を意味します。 たとえば、_http：//www.w3.org/pub/WWW/_のオリジンサーバでのリクエストは次のようになります。

GET/pub/WWW/HTTP/1.1
Host: www.w3.org

一致する場合

If-Match request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このヘッダーは、このタグの特定の値が ETag で表される特定のエンティティタグと一致する場合にのみ、要求されたメソッドの実行をサーバーに要求します。 一般的な構文は次のとおりです。

If-Match : entity-tag

アスタリスク（*）は任意のエンティティに一致し、トランザクションはエンティティが存在する場合にのみ続行されます。 可能な例は次のとおりです。

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

一致するエンティティタグがない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず、412（前提条件失敗）応答を返す必要があります。

If-Modified-Since

If-Modified-Since request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このフィールドで指定された時間以降に要求されたURLが変更されていない場合、エンティティはサーバーから返されません。代わりに、メッセージ本文なしで304（変更なし）応答が返されます。 if-modified-sinceの一般的な構文は次のとおりです。

If-Modified-Since : HTTP-date

フィールドの例は次のとおりです。

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

一致するエンティティタグがない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず、412（前提条件失敗）応答を返す必要があります。

If-None-Match

If-None-Match request-headerフィールドは、条件付きにするメソッドとともに使用されます。 このヘッダーは、このタグの特定の値の1つが ETag で表される特定のエンティティタグと一致する場合にのみ、要求されたメソッドを実行するようサーバーに要求します。 一般的な構文は次のとおりです。

If-None-Match : entity-tag

アスタリスク（*）は任意のエンティティと一致し、トランザクションはエンティティが存在しない場合にのみ続行されます。 可能な例は次のとおりです。

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If範囲

If-Range request-headerフィールドを条件付きGETで使用して、変更されていない場合はエンティティの一部のみ、変更されている場合はエンティティ全体を要求できます。 一般的な構文は次のとおりです。

If-Range : entity-tag | HTTP-date

エンティティタグまたは日付を使用して、すでに受信した部分エンティティを識別できます。 例えば：

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

ここで、指定された日付以降にドキュメントが変更されていない場合、サーバーはRangeヘッダーで指定されたバイト範囲を返します。それ以外の場合は、すべての新しいドキュメントを返します。

未修正の場合

If-Unmodified-Since request-headerフィールドは、条件付きにするメソッドとともに使用されます。 一般的な構文は次のとおりです。

If-Unmodified-Since : HTTP-date

このフィールドで指定された時間以降に要求されたリソースが変更されていない場合、サーバーはIf-Unmodified-Sinceヘッダーが存在しないかのように要求された操作を実行する必要があります。 例えば：

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

リクエストの結果が2xxまたは412ステータス以外の場合、_If-Unmodified-Since_ヘッダーは無視する必要があります。

マックスフォワード

Max-Forwards request-headerフィールドは、リクエストを次のインバウンドサーバーに転送できるプロキシまたはゲートウェイの数を制限するためのTRACEおよびOPTIONSメソッドを備えたメカニズムを提供します。 一般的な構文は次のとおりです。

Max-Forwards : n

Max-Forwards値は、この要求メッセージを転送できる残りの回数を示す10進整数です。 これは、TRACEメソッドを使用したデバッグに役立ち、無限ループを回避します。 例えば：

Max-Forwards : 5

HTTP仕様で定義されている他のすべてのメソッドでは、Max-Forwardsヘッダーフィールドは無視される場合があります。

プロキシ承認

Proxy-Authorization request-headerフィールドを使用すると、クライアントは認証を必要とするプロキシに対して自分自身（またはそのユーザー）を識別できます。 一般的な構文は次のとおりです。

Proxy-Authorization : credentials

Proxy-Authorizationフィールドの値は、リクエストされているリソースのプロキシまたはレルムのユーザーエージェントの認証情報を含む資格情報で構成されます。

範囲

Range request-headerフィールドは、ドキュメントから要求されたコンテンツの部分的な範囲を指定します。 一般的な構文は次のとおりです。

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

byte-range-specのfirst-byte-pos値は、範囲の最初のバイトのバイトオフセットを示します。 last-byte-pos値は、範囲内の最後のバイトのバイトオフセットを示します。つまり、指定されたバイト位置は包括的です。 バイト単位をバイトとして指定できます。 バイトオフセットはゼロから始まります。 いくつかの簡単な例は次のとおりです。

- The first 500 bytes
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

複数の範囲をコンマで区切ってリストできます。 コンマで区切られたバイト範囲の最初の数字が欠落している場合、範囲はドキュメントの最後からカウントされると想定されます。 2番目の数字が欠落している場合、範囲はバイトnから文書の終わりまでです。

リファラー

Referer request-headerフィールドを使用すると、クライアントはURLが要求されたリソースのアドレス（URI）を指定できます。 一般的な構文は次のとおりです。

Referer : absoluteURI | relativeURI

次に簡単な例を示します。

Referer: http://www.finddevguides.org/http/index

フィールド値が相対URIである場合、_Request-URI_を基準にして解釈する必要があります。

TE

TE request-headerフィールドは、応答でどの拡張_transfer-coding_を受け入れるか、およびチャンク_transfer-coding_のトレーラフィールドを受け入れるかどうかを示します。 一般的な構文は次のとおりです。

TE   : t-codings

キーワード「trailers」の存在は、クライアントがチャンク転送コーディングのトレーラフィールドを受け入れようとしていることを示し、次のいずれかの方法で指定されます。

TE: deflate
TE:
TE: trailers, deflate;q=0.5

TEフィールド値が空の場合、またはTEフィールドが存在しない場合、転送コーディングのみがチャンクされます。 転送コーディングのないメッセージは常に受け入れられます。

ユーザーエージェント

User-Agent request-headerフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれています。 一般的な構文は次のとおりです。

User-Agent : product | comment

例：

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

サーバー応答ヘッダー

受諾範囲

Accept-Ranges response-headerフィールドを使用すると、サーバーはリソースに対する範囲要求の受け入れを示すことができます。 一般的な構文は次のとおりです。

Accept-Ranges  : range-unit | none

たとえば、バイト範囲要求を受け入れるサーバーは次を送信できます。

Accept-Ranges: bytes

リソースに対する範囲要求の種類を受け入れないサーバーは、以下を送信できます。

Accept-Ranges: none

これは、範囲要求を試行しないようにクライアントにアドバイスします。

Age

Age response-headerフィールドは、発信元サーバーで応答（またはその再検証）が生成されてからの送信者の推定時間を伝えます。 一般的な構文は次のとおりです。

Age : delta-seconds

年齢の値は負でない10進整数で、秒単位の時間を表します。 次に簡単な例を示します。

Age: 1030

キャッシュを含むHTTP/1.1サーバーは、独自のキャッシュから生成されるすべての応答にAgeヘッダーフィールドを含める必要があります。

ETag

_ETag_応答ヘッダーフィールドは、要求されたバリアントのエンティティタグの現在の値を提供します。 一般的な構文は次のとおりです。

ETag :  entity-tag

ここにいくつかの簡単な例があります：

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

ロケーション

_Location_応答ヘッダーフィールドは、受信者を完了のためにRequest-URI以外の場所にリダイレクトするために使用されます。 一般的な構文は次のとおりです。

Location : absoluteURI

次に簡単な例を示します。

Location: http://www.finddevguides.org/http/index

Content-Locationヘッダーフィールドは、Content-Locationがリクエストに含まれるエンティティの元の場所を識別するという点でLocationと異なります。

プロキシ認証

Proxy-Authenticate response-headerフィールドは、407（Proxy Authentication Required）応答の一部として含める必要があります。 一般的な構文は次のとおりです。

Proxy-Authenticate  : challenge

再試行後

Retry-After response-headerフィールドを503（Service Unavailable）応答と共に使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。 一般的な構文は次のとおりです。

Retry-After : HTTP-date | delta-seconds

例：

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

後者の例では、遅延は2分です。

サーバ

Server response-headerフィールドには、要求を処理するためにオリジンサーバーが使用するソフトウェアに関する情報が含まれています。 一般的な構文は次のとおりです。

Server : product | comment

次に簡単な例を示します。

Server: Apache/2.2.14 (Win32)

応答がプロキシを介して転送される場合、プロキシアプリケーションはサーバーの応答ヘッダーを変更してはなりません。

セットクッキー

Set-Cookie response-headerフィールドには、このURLで保持する情報の名前と値のペアが含まれています。 一般的な構文は次のとおりです。

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie応答ヘッダーは、トークンSet-Cookieの後に1つ以上のCookieのコンマ区切りリストが続きます。 オプションとして指定できる値は次のとおりです。

S.N.	Options and Description
1	Comment=comment このオプションを使用して、Cookieに関連付けられたコメントを指定できます。
2	Domain=domain Domain属性は、Cookieが有効なドメインを指定します。
3	Expires=Date-time Cookieの有効期限が切れる日付。 空白の場合、訪問者がブラウザを終了すると、Cookieは期限切れになります。
4	Path=path Path属性は、このCookieが適用されるURLのサブセットを指定します。
5	Secure セキュア接続下でのみクッキーを返すようにユーザーエージェントに指示します。

以下は、サーバーによって生成される単純なCookieヘッダーの例です。

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

Vary response-headerフィールドは、エンティティに複数のソースがあることを指定しているため、指定されたリクエストヘッダーのリストによって異なる場合があります。 一般的な構文は次のとおりです。

Vary : field-name

複数のヘッダーをコンマで区切って指定し、アスタリスク「*」の値を指定すると、未指定のパラメーターが要求ヘッダーに限定されないことを通知できます。 次に簡単な例を示します。

Vary: Accept-Language, Accept-Encoding

ここで、フィールド名は大文字と小文字を区別しません。

WWW-認証

WWW-Authenticate response-headerフィールドは、401（無許可）応答メッセージに含める必要があります。 フィールド値は、Request-URIに適用可能な認証スキームとパラメーターを示す少なくとも1つのチャレンジで構成されます。 一般的な構文は次のとおりです。

WWW-Authenticate : challenge

WWW-Authenticateフィールドの値には複数のチャレンジが含まれる場合があります。または、複数のWWW-Authenticateヘッダーフィールドが提供される場合、チャレンジ自体のコンテンツに認証パラメーターのコンマ区切りリストを含めることができます。 次に簡単な例を示します。

WWW-Authenticate: BASIC realm="Admin"

エンティティヘッダー

許可する

Allow entity-headerフィールドには、Request-URIで識別されるリソースでサポートされるメソッドのセットがリストされます。 一般的な構文は次のとおりです。

Allow : Method

複数のメソッドをコンマで区切って指定できます。 次に簡単な例を示します。

Allow: GET, HEAD, PUT

このフィールドは、クライアントが他の方法を試みることを防ぐことはできません。

コンテンツエンコード

Content-Encoding entity-headerフィールドは、メディアタイプの修飾子として使用されます。 一般的な構文は次のとおりです。

Content-Encoding : content-coding

content-codingは、Request-URIによって識別されるエンティティの特性です。 次に簡単な例を示します。

Content-Encoding: gzip

要求メッセージ内のエンティティのコンテンツコーディングがオリジンサーバに受け入れられない場合、サーバは415（サポートされていないメディアタイプ）のステータスコードで応答する必要があります。

コンテンツ言語

Content-Language entity-headerフィールドは、囲まれたエンティティの対象オーディエンスの自然言語を示します。 一般的な構文は次のとおりです。

Content-Language : language-tag

複数の視聴者を対象としたコンテンツには、複数の言語がリストされる場合があります。 次に簡単な例を示します。

Content-Language: mi, en

Content-Languageの主な目的は、ユーザーがユーザー自身の優先言語に従ってエンティティを識別および区別できるようにすることです。

コンテンツ長

Content-Length entity-headerフィールドは、10進数のOCTETで受信者に送信されたエンティティ本体のサイズ、またはHEADメソッドの場合は送信されたエンティティ本体のサイズを示します。リクエストがGETであった場合。 一般的な構文は次のとおりです。

Content-Length : DIGITS

次に簡単な例を示します。

Content-Length: 3495

ゼロ以上の任意のContent-Lengthは有効な値です。

コンテンツの場所

Content-Location entity-headerフィールドは、要求されたリソースのURIとは別の場所からアクセスできる場合、メッセージに含まれるエンティティのリソースの場所を提供するために使用できます。 一般的な構文は次のとおりです。

Content-Location:  absoluteURI | relativeURI

次に簡単な例を示します。

Content-Location: http://www.finddevguides.org/http/index

Content-Locationの値は、エンティティのベースURIも定義します。

コンテンツ-MD5

Content-MD5 entity-headerフィールドは、受信時にメッセージの整合性をチェックするためのエンティティのMD5ダイジェストを提供するために使用できます。 一般的な構文は次のとおりです。

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

次に簡単な例を示します。

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5ダイジェストは、エンティティ本体のコンテンツに基づいて計算されます。これには、適用されたコンテンツコーディングが含まれますが、メッセージ本文に適用される転送エンコードは含まれません。

コンテンツ範囲

Content-Range entity-headerフィールドは、部分的なエンティティ本体とともに送信され、完全なエンティティ本体のどこに部分的な本体を適用するかを指定します。 一般的な構文は次のとおりです。

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

エンティティに合計1234バイトが含まれると仮定した、byte-content-range-spec値の例：

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

HTTPメッセージに単一の範囲のコンテンツが含まれる場合、このコンテンツはContent-Rangeヘッダーと、実際に転送されたバイト数を示すContent-Lengthヘッダーと共に送信されます。 例えば、

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

コンテンツタイプ

Content-Type entity-headerフィールドは、受信者に送信されたエンティティ本体のメディアタイプ、またはHEADメソッドの場合、送信されたメディアタイプ（リクエストがGETであった場合）を示します。 一般的な構文は次のとおりです。

Content-Type : media-type

以下はその例です。

Content-Type: text/html; charset=ISO-8859-4

有効期限

Expires entity-headerフィールドは、応答が古くなったと見なされる日時を示します。 一般的な構文は次のとおりです。

Expires : HTTP-date

以下はその例です。

Expires: Thu, 01 Dec 1994 16:00:00 GMT

最終更新日

Last-Modified entity-headerフィールドは、オリジンサーバがバリアントが最後に変更されたと信じる日時を示します。 一般的な構文は次のとおりです。

Last-Modified: HTTP-date

以下はその例です。

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

HTTP-キャッシュ

HTTPは通常、応答キャッシュを使用することでパフォーマンスを改善できる分散情報システムに使用されます。 HTTP/1.1プロトコルには、キャッシュを機能させるための要素が多数含まれています。

HTTP/1.1でのキャッシュの目標は、多くの場合にリクエストを送信する必要をなくし、他の多くの場合に完全な応答を送信する必要をなくすことです。

HTTP/1.1の基本的なキャッシュメカニズムは、サーバーが有効期限とバリデーターを指定するキャッシュに対する暗黙のディレクティブです。 この目的のために Cache-Control ヘッダーを使用します。

*Cache-Control* ヘッダーを使用すると、クライアントまたはサーバーは、要求または応答でさまざまなディレクティブを送信できます。 これらのディレクティブは通常、デフォルトのキャッシュアルゴリズムをオーバーライドします。 キャッシングディレクティブは、コンマ区切りリストで指定されます。 例えば：

Cache-control: no-cache

クライアントは、HTTP要求で次のキャッシュ要求ディレクティブを使用できます。

S.N.	Cache Request Directive and Description
1	no-cache キャッシュは、元のサーバーとの再検証が成功しない限り、後続の要求を満たすために応答を使用してはなりません。
2	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
3	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
4	max-stale [ = seconds ] 有効期限を超えた応答をクライアントが受け入れようとしていることを示します。 秒が指定されている場合、その時間以上に期限切れになってはいけません。
5	min-fresh = seconds クライアントが、フレッシュネスライフタイムが現在の経過時間に秒単位で指定された時間を足したものよりも小さくない応答を受け入れる意思があることを示します。
6	no-transform エンティティ本体を変換しません。
7	only-if-cached 新しいデータを取得しません。 キャッシュは、ドキュメントがキャッシュ内にある場合にのみドキュメントを送信でき、新しいコピーが存在するかどうかを確認するために配信元サーバーに接続しないでください。

サーバーは、次のキャッシュ応答ディレクティブをHTTP応答で使用できます。

S.N.	Cache Response Directive and Description
1	public 応答が任意のキャッシュによってキャッシュされる可能性があることを示します。
2	private 応答メッセージのすべてまたは一部が単一のユーザー向けであり、共有キャッシュによってキャッシュされてはならないことを示します。
3	no-cache キャッシュは、元のサーバーで正常に再検証されない限り、後続の要求を満たすために応答を使用してはなりません。
4	no-store キャッシュには、クライアントのリクエストやサーバーの応答に関する情報を保存しないでください。
5	no-transform エンティティ本体を変換しません。
6	must-revalidate キャッシュは、使用する前に古いドキュメントのステータスを確認する必要があり、期限切れのドキュメントは使用しないでください。
7	proxy-revalidate proxy-revalidateディレクティブは、非共有ユーザーエージェントキャッシュに適用されないことを除いて、must-revalidateディレクティブと同じ意味を持ちます。
8	max-age = seconds クライアントが、指定された秒単位の時間より長くない応答を受け入れることを示します。
9	s-maxage = seconds このディレクティブで指定された最大年齢は、max-ageディレクティブまたはExpiresヘッダーで指定された最大年齢を上書きします。 s-maxageディレクティブは、プライベートキャッシュによって常に無視されます。

HTTP-URLエンコード

HTTP URLは、ASCII _character-set_を使用してインターネット経由でのみ送信できます。ASCII_character-set_には、ASCIIセット外の文字が含まれていることがよくあります。 したがって、これらの安全でない文字は、*％*に続いて2桁の16進数で置き換える必要があります。

次の表は、サーバーに渡す前にURLで使用できる文字のASCII記号とその置換を示しています。

ASCII	Symbol	Replacement
< 32		Encode with %xx where xx is the hexadecimal representation of the character.
32	space	+ or %20
33	!	%21
34	"	%22
35	#	%23
36	$	%24
37	%	%25
38	&	%26
39	'	%27
40	(	%28
41	)	%29
42	*	*
43	+	%2B
44	,	%2C
45	-	-
46	.	.
47	/	%2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	%3A
59	;	%3B
60	<	%3C
61	=	%3D
62	>	%3E
63	?	%3F
64	@	%40
65	A	A
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	I	I
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	%5B
92	\	%5C
93	]	%5D
94	^	%5E
95	_	_
96	`	%60
97	a	a
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	i	i
106	j	j
107	k	k
108	l	l
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	u	u
118	v	v
119	w	w
120	x	x
121	y	y
122	z	z
123	\{	%7B
124
%7C	125	}
%7D	126	~
%7E	127
%7F	> 127

HTTP-セキュリティ

HTTPはインターネット上の通信に使用されるため、アプリケーション開発者、情報プロバイダー、およびユーザーはHTTP/1.1のセキュリティ制限に注意する必要があります。 この説明には、ここで言及した問題に対する決定的な解決策は含まれていませんが、セキュリティリスクを軽減するためのいくつかの提案がなされています。

個人情報漏洩

HTTPクライアントは、多くの場合、ユーザーの名前、場所、メールアドレス、パスワード、暗号化キーなどの大量の個人情報を所有しています。 したがって、この情報がHTTPプロトコルを介して他のソースに意図せずに漏洩しないように、十分に注意する必要があります。

• すべての機密情報は、暗号化された形式でサーバーに保存する必要があります。
• サーバーの特定のソフトウェアバージョンを明らかにすると、サーバーマシンがセキュリティホールを含むことが知られているソフトウェアに対する攻撃に対してより脆弱になる可能性があります。
• ネットワークファイアウォールを介してポータルとして機能するプロキシは、ファイアウォールの背後にあるホストを識別するヘッダー情報の転送に関して特別な予防措置を講じる必要があります。
• 「差出人」フィールドで送信される情報は、ユーザーのプライバシーの利益またはサイトのセキュリティポリシーと競合する可能性があるため、ユーザーがフィールドのコンテンツを無効化、有効化、および変更できるようにするまで送信しないでください。
• 参照元ページが安全なプロトコルで転送された場合、クライアントは（安全でない）HTTP要求にRefererヘッダーフィールドを含めないでください。
• HTTPプロトコルを使用するサービスの作成者は、データがRequest-URIでエンコードされるため、機密データの送信にGETベースのフォームを使用しないでください。

ファイルおよびパス名ベースの攻撃

文書は、サーバー管理者が意図したものだけになるように、HTTP要求によって返される文書に制限する必要があります。

たとえば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムは、パスコンポーネントとして '..' を使用して、現在のディレクトリレベルより上のディレクトリレベルを示します。 そのようなシステムでは、HTTPサーバーは、HTTPサーバー経由でアクセスできるように意図されたリソース以外のリソースへのアクセスを許可する場合、Request-URIでそのような構成を許可しなければなりません（MUST）。

DNSスプーフィング

HTTPを使用するクライアントは、ドメインネームサービスに大きく依存しているため、一般に、IPアドレスとDNS名の意図的な誤関連付けに基づくセキュリティ攻撃を受けやすくなります。 したがって、クライアントは、IP番号/DNS名の関連付けの継続的な有効性を想定する際に注意する必要があります。

HTTPクライアントがパフォーマンスの向上を達成するためにホスト名検索の結果をキャッシュする場合、DNSによって報告されたTTL情報を監視する必要があります。 HTTPクライアントがこの規則を遵守しない場合、以前にアクセスしたサーバーのIPアドレスが変更されると、それらが偽装される可能性があります。

ロケーションヘッダーとなりすまし

単一のサーバーが相互に信頼しない複数の組織をサポートする場合、リソースを無効にしようとしていないことを確認するために、その組織の制御下で生成される応答のLocationおよびContent Locationヘッダーの値をチェックする必要があります彼らには権限がありません。

認証資格

既存のHTTPクライアントとユーザーエージェントは通常、認証情報を無期限に保持します。 HTTP/1.1は、サーバーがクライアントにこれらのキャッシュされた資格情報を破棄するよう指示する方法を提供しません。これは大きなセキュリティリスクです。

この問題の部分にはいくつかの回避策があるため、スクリーンセーバー、アイドルタイムアウト、およびこの問題に固有のセキュリティ問題を軽減する他の方法でパスワード保護を使用することをお勧めします。

プロキシとキャッシュ

HTTPプロキシは中間者であり、中間者攻撃の機会を表します。 プロキシは、セキュリティ関連の情報、個々のユーザーと組織に関する個人情報、およびユーザーとコンテンツプロバイダーに帰属する専有情報にアクセスできます。

プロキシオペレータは、機密情報を含むまたは転送するシステムを保護するため、プロキシが実行されるシステムを保護する必要があります。

キャッシュの内容は悪意のある悪用の魅力的な標的であるため、キャッシュプロキシは追加の潜在的な脆弱性を提供します。 したがって、キャッシュの内容は機密情報として保護する必要があります。

HTTP-メッセージの例

例1

_finddevguides.com_で実行されているWebサーバーから hello ページをフェッチするためのHTTPリクエスト。

クライアントリクエスト

GET/hello HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

サーバー応答

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
   <body>

   <h1>Hello, World!</h1>

   </body>
</html>

例2

_finddevguides.com_で実行されているWebサーバーに存在しない tl ページをフェッチするためのHTTPリクエスト。

クライアントリクエスト

GET/tl HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

サーバー応答

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>

<head>
   <title>404 Not Found</title>
</head>

<body>
   <h1>Not Found</h1>
   <p>The requested URL/tl was not found on this server.</p>
</body>

</html>

実施例３

_finddevguides.com_で実行されているWebサーバーから hello ページをフェッチするためのHTTPリクエストですが、リクエストは正しくないHTTPバージョンで送信されます。

クライアントリクエスト

GET/hello HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

サーバー応答

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>

<head>
   <title>400 Bad Request</title>
</head>

<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>

</html>

実施例４

_finddevguides.com_で実行されているWebサーバーの process.cgi CGIページにフォームデータをポストするためのHTTPリクエスト。 サーバーは、Cookieとして設定した後、渡された名前を返します。

クライアントリクエスト

POST/cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.finddevguides.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

サーバー応答

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=finddevguides.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>

<body>
   <h1>Hello Zara Ali</h1>
</body>

</html>