HTTP-クイックガイド

ハイパーテキスト転送プロトコル(HTTP)は、分散型の協調型ハイパーメディア情報システム向けのアプリケーションレベルのプロトコルです。これは、1990年以来のワールドワイドウェブ(つまりインターネット)のデータ通信の基盤です。HTTPは、要求メソッド、エラーコード、およびヘッダーの拡張を使用して、他の目的にも使用できる汎用のステートレスプロトコルです。

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

基本的な機能

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

  • HTTP is connectionless:HTTPクライアントすなわち。ブラウザはHTTP要求を開始し、要求が行われた後、クライアントはサーバーから切断し、応答を待ちます。サーバーは要求を処理し、クライアントとの接続を再確立して応答を送り返します。

  • HTTP is media independent:つまり、クライアントとサーバーの両方がデータコンテンツの処理方法を知っている限り、あらゆるタイプのデータをHTTPで送信できます。これは、クライアントとサーバーが適切なMIMEタイプを使用してコンテンツタイプを指定するために必要です。

  • HTTP is stateless:上記のように、HTTPはコネクションレス型であり、これはHTTPがステートレスプロトコルであるという直接的な結果です。サーバーとクライアントは、現在の要求の間のみお互いを認識します。その後、二人はお互いを忘れます。プロトコルのこの性質により、クライアントもブラウザも、Webページ全体の異なる要求間で情報を保持できません。

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

基本アーキテクチャ

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

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

クライアント

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

サーバ

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

この章では、重要な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

ユニフォームリソース識別子(URI)

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

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

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

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

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

日付/時刻形式

すべての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オープンで拡張可能なデータタイピングとタイプネゴシエーションを提供するためのヘッダーフィールド。すべてのMedia-type値は、Internet Assigned Number Authority((IANA)に登録されています。メディアタイプを指定するための一般的な構文は次のとおりです。

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

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

Accept: image/gif

言語タグ

HTTPは、内で言語タグを使用します Accept-Language そして Content-Language田畑。言語タグは、1つ以上の部分で構成されています。1次言語タグと、場合によっては空の一連のサブタグです。

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

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

タグの例は次のとおりです。

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

2文字のプライマリタグがISO-639言語の略語であり、2文字の最初のサブタグがISO-3166国コードである場合。

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

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

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

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

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


     
  • A Start-line
  • Zero or more header fields followed by CRLF
  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
  • Optionally a message-body

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

メッセージスタートライン

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

start-line = Request-Line | Status-Line

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

GET /hello.htm 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 Deaderフィールドは、要求または応答、またはメッセージ本文で送信されたオブジェクトに関する必要な情報を提供します。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>

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


     
  • A Request-line
  • Zero or more header (General|Request|Entity) fields followed by CRLF
  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
  • Optionally a message-body

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

メッセージリクエストライン

Request-Lineは、メソッドトークンで始まり、Request-URIとプロトコルバージョンが続き、CRLFで終わります。要素はスペースSP文字で区切られます。

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

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

リクエスト方法

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

SN 方法と説明
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はUniformResource Identifierであり、リクエストを適用するリソースを識別します。以下は、URIを指定するために最も一般的に使用されるフォームです。

Request-URI = "*" | absoluteURI | abs_path | authority
SN 方法と説明
1 アスタリスク *HTTPリクエストが特定のリソースではなくサーバー自体に適用される場合に使用され、使用されるメソッドが必ずしもリソースに適用されるとは限らない場合にのみ許可されます。例えば:

OPTIONS * HTTP/1.1

2 ザ・ absoluteURIプロキシに対してHTTPリクエストが行われるときに使用されます。プロキシは、リクエストを転送するか、有効なキャッシュからサービスを提供し、レスポンスを返すように要求されます。例えば:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

3 Request-URIの最も一般的な形式は、オリジンサーバーまたはゲートウェイ上のリソースを識別するために使用される形式です。たとえば、上記のリソースをオリジンサーバーから直接取得したいクライアントは、ホスト「www.w3.org」のポート80へのTCP接続を作成し、次の行を送信します。

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

絶対パスを空にすることはできないことに注意してください。元のURIに何も存在しない場合は、「/」(サーバールート)として指定する必要があります

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

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

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

  • Accept-Charset

  • Accept-Encoding

  • Accept-Language

  • Authorization

  • Expect

  • From

  • Host

  • If-Match

  • If-Modified-Since

  • If-None-Match

  • If-Range

  • If-Unmodified-Since

  • Max-Forwards

  • Proxy-Authorization

  • Range

  • Referer

  • TE

  • User-Agent

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

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

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

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

ここでは、サーバーからプランHTMLページをフェッチしているため、サーバーにリクエストデータを送信していません。接続はここで使用される一般的なヘッダーであり、残りのヘッダーは要求ヘッダーです。以下は、リクエストメッセージ本文を使用してフォームデータをサーバーに送信するもう1つの例です。

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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.tutorialspoint.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応答メッセージで応答します。


     
  • A Status-line
  • Zero or more header (General|Response|Entity) fields followed by CRLF
  • An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
  • Optionally a message-body

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

メッセージステータス-行

プロトコルバージョンとそれに続く数値ステータスコードおよび関連するテキストフレーズで構成されるステータス行。要素はスペースSP文字で区切られます。

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

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

HTTPバージョン

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

HTTP-Version = HTTP/1.1

ステータスコード

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

SN コードと説明
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ヘッダーフィールドとは何かを確認しましょう。

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

  • Accept-Ranges

  • Age

  • ETag

  • Location

  • Proxy-Authenticate

  • Retry-After

  • Server

  • Vary

  • WWW-Authenticate

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

応答メッセージの例

それでは、すべてをまとめて、フェッチするリクエストのHTTP応答を作成しましょう。 hello.htm tutorialspoint.comで実行されているWebサーバーのページ

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 /t.html 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 / 1.1の一般的なメソッドのセットを以下に定義します。このセットは、要件に基づいて拡張できます。これらのメソッド名では大文字と小文字が区別されるため、大文字で使用する必要があります。

SN 方法と説明
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.htmをフェッチする簡単な例です。

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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.htmに関するヘッダー情報をフェッチする簡単な例です。

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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.tutorialspoint.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.htm サーバーのルート:

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

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

サーバーは、指定されたエンティティ本体をに格納します hello.htm ファイルを作成し、次の応答をクライアントに送り返します。

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.htm サーバーのルート:

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

サーバーは言及されたファイルを削除します hello.htm そして、次の応答をクライアントに送り返します。

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サーバーへのネットワーク接続を確立するためにクライアントによって使用されます。次の例では、ホストtutorialspoint.comで実行されているWebサーバーとの接続を要求します。

CONNECT www.tutorialspoint.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メソッドは、WebサーバーでサポートされているHTTPメソッドやその他のオプションを見つけるためにクライアントによって使用されます。クライアントは、OPTIONSメソッドのURLを指定するか、サーバー全体を参照するためにアスタリスク(*)を指定できます。次の例では、tutorialspoint.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.tutorialspoint.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)
Content-Type: message/http
Content-Length: 39
Connection: Closed

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

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

SN コードと説明
1 1xx: Informational
これは、リクエストを受け取り、プロセスを継続することを意味します。
2 2xx: Success
これは、アクションが正常に受信され、理解され、受け入れられたことを意味します。
3 3xx: Redirection
これは、リクエストを完了するためにさらにアクションを実行する必要があることを意味します。
4 4xx: Client Error
これは、リクエストに不正な構文が含まれているか、実行できないことを意味します
5 5xx: Server Error
サーバーは明らかに有効な要求を実行できませんでした

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

1xx:情報

メッセージ: 説明:
100続行 リクエストの一部のみがサーバーによって受信されましたが、それが拒否されない限り、クライアントはリクエストを続行する必要があります
101スイッチングプロトコル サーバーはプロトコルを切り替えます

2xx:成功

メッセージ: 説明:
200 OK リクエストはOKです
201作成済み リクエストが完了し、新しいリソースが作成されます 
202承認済み リクエストは処理のために受け入れられましたが、処理は完了していません
203信頼できない情報 エンティティヘッダーの情報は、元のサーバーからではなく、ローカルまたはサードパーティのコピーからのものです。
204コンテンツなし 応答にはステータスコードとヘッダーが示されていますが、応答にはエンティティ本体がありません。
205コンテンツのリセット ブラウザは、追加の入力のために、このトランザクションに使用されたフォームをクリアする必要があります。
206部分的なコンテンツ サーバーは、要求されたサイズの部分データを返しています。Rangeヘッダーを指定するリクエストに応答して使用されます。サーバーは、Content-Rangeヘッダーを使用して応答に含まれる範囲を指定する必要があります。

3xx:リダイレクト

メッセージ: 説明:
300の複数の選択肢 リンクリスト。ユーザーはリンクを選択してその場所に移動できます。最大5つのアドレス  
301恒久的に移動 リクエストされたページは新しいURLに移動しました 
302が見つかりました リクエストされたページは一時的に新しいURLに移動しました 
303その他を見る リクエストされたページは別のURLにあります 
304変更なし これは、If-Modified-SinceまたはIf-None-Matchヘッダーへの応答コードであり、指定された日付以降、URLは変更されていません。
305プロキシを使用する 要求されたURLには、Locationヘッダーに記載されているプロキシを介してアクセスする必要があります。
306未使用 このコードは以前のバージョンで使用されていました。使用されなくなりましたが、コードは予約されています
307一時的なリダイレクト リクエストされたページは一時的に新しいURLに移動しました

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

メッセージ: 説明:
400不正な要求 サーバーはリクエストを理解しませんでした
401無許可 リクエストされたページにはユーザー名とパスワードが必要です
402支払いが必要 このコードはまだ使用できません
403禁止します リクエストされたページへのアクセスは禁止されています
404お探しのページが見つかりませんでした サーバーは要求されたページを見つけることができません
405メソッドは許可されていません リクエストで指定されたメソッドは許可されていません
406受け入れられない サーバーは、クライアントによって受け入れられない応答のみを生成できます
407プロキシ認証が必要 このリクエストを処理する前に、プロキシサーバーで認証する必要があります
408リクエストタイムアウト サーバーが待機する準備ができているよりも、要求に時間がかかりました
409競合 競合のため、リクエストを完了できませんでした
410ゴーン リクエストされたページは利用できなくなりました 
411必要な長さ 「Content-Length」は定義されていません。サーバーはそれなしではリクエストを受け入れません 
412前提条件が失敗しました サーバーによってfalseと評価されたリクエストで指定された前提条件
413要求エンティティが大きすぎます リクエストエンティティが大きすぎるため、サーバーはリクエストを受け入れません
414リクエストURLが長すぎます URLが長すぎるため、サーバーはリクエストを受け入れません。「post」リクエストを長いクエリ情報を含む「get」リクエストに変換すると発生します 
415サポートされていないメディアタイプ メディアタイプがサポートされていないため、サーバーはリクエストを受け入れません 
416要求された範囲が満たされていません 要求されたバイト範囲は使用できず、範囲外です。
417期待に失敗しました このサーバーは、Expectrequest-headerフィールドで指定された期待値を満たすことができませんでした。

5xx:サーバーエラー

メッセージ: 説明:
500内部サーバーエラー リクエストは完了しませんでした。サーバーが予期しない条件を満たしました
501は実装されていません リクエストは完了しませんでした。サーバーは必要な機能をサポートしていませんでした
502不正なゲートウェイ リクエストは完了しませんでした。サーバーがアップストリームサーバーから無効な応答を受信しました
503サービスを利用できません リクエストは完了しませんでした。サーバーが一時的に過負荷またはダウンしています
504ゲートウェイのタイムアウト ゲートウェイがタイムアウトしました
505HTTPバージョンはサポートされていません サーバーは「httpプロトコル」バージョンをサポートしていません

HTTP Deaderフィールドは、要求または応答、またはメッセージ本文で送信されたオブジェクトに関する必要な情報を提供します。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リクエストで使用できる重要なキャッシュリクエストディレクティブは次のとおりです。

SN キャッシュリクエストのディレクティブと説明
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応答で使用できる重要なキャッシュ応答ディレクティブは次のとおりです。

SN キャッシュリクエストのディレクティブと説明
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 : "Connection"

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

Connection: Closed

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

Connection: keep-alive

日付

すべての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ディレクティブであり、下位互換性のためにHTTP1.1で維持されています。今後、新しいPragmaディレクティブは定義されません。

トレーラー

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

Trailer : field-name

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

  • Transfer-Encoding

  • Content-Length

  • Trailer

転送エンコーディング

転送エンコード一般ヘッダフィールドは、変換のタイプが安全送信者と受信者の間に転送するためにメッセージボディに適用されたものを示しています。transfer-encodingsはメッセージのプロパティであり、entity-bodyのプロパティではないため、これはcontent-encodingと同じではありません。次に、Transfer-Encodingヘッダーフィールドの構文を示します。

Transfer-Encoding: chunked

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

アップグレード

アップグレードの一般ヘッダは、クライアントがサポートしている追加の通信プロトコルを指定することができ、サーバはそれがスイッチプロトコルに適当であると認める場合には、使用したいと思います。例えば:

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

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

経由

ビア一般ヘッダは、中間プロトコルおよび受信者を示すためにゲートウェイやプロキシによって使用されなければなりません。たとえば、リクエストメッセージを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 : warn-code SP warn-agent SP warn-text SP warn-date

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

受け入れる

受け入れリクエストヘッダフィールドは、応答のために許容される特定のメディアタイプを指定するために使用することができます。一般的な構文は次のとおりです。

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/x-c 推奨されるメディアタイプですが、存在しない場合は、 text/x-dvi エンティティ、およびそれが存在しない場合は、 text/plain エンティティ。

Accept-Charset

受け入れ、文字セットリクエストヘッダフィールドは、文字セットは、応答のために許容可能であるかを示すために使用することができます。一般的な構文は次のとおりです。

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

受け入れエンコードリクエストヘッダフィールドは、そのまま使用することが同様であるが、応答に許容される内容コーディングを制限します。一般的な構文は次のとおりです。

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: language [q=qvalue]

複数の言語をコンマで区切ってリストすることができ、オプションのqvalueは、0から1のスケールで非優先言語の許容可能な品質レベルを表します。以下に例を示します。

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

承認

認可リクエストヘッダフィールド値は要求されたリソースのレルムのユーザエージェントの認証情報を含む資格情報から成ります。一般的な構文は次のとおりです。

Authorization : credentials

HTTP / 1.0仕様では、BASIC認証スキームが定義されています。ここで、認証パラメータは次の文字列です。 username:password Base64でエンコードされます。次に例を示します。

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

にデコードされる値は guest:guest123 どこ guest はユーザーIDであり、 guest123 はパスワードです。

クッキー

クッキーリクエスト・ヘッダー・フィールドの値は、そのURLのために格納された情報の名前/値ペアを含んでいます。一般的な構文は次のとおりです。

Cookie: name=value

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

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

期待する

[リクエストヘッダーの期待]フィールドは、特定のサーバーの動作がクライアントに必要であることを示すために使用されます。一般的な構文は次のとおりです。

Expect : 100-continue | expectation-extension

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

から

以下からのリクエストヘッダフィールドは、要求元のユーザエージェントを制御し、人間のユーザのインターネット電子メールアドレスが含まれています。以下は簡単な例です。

From: [email protected]

このヘッダーフィールドは、ログ記録の目的で、および無効または不要な要求のソースを識別する手段として使用できます。

ホスト

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

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

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

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

If-Match

もしマッチリクエストヘッダフィールドは、条件付きにする方法に使用されます。このヘッダーは、このタグの指定された値がで表される指定されたエンティティタグと一致する場合にのみ、要求されたメソッドを実行するようサーバーに要求します。ETag。一般的な構文は次のとおりです。

If-Match : entity-tag

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

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

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

変更された場合-以降

場合修飾-のでリクエストヘッダフィールドが条件付きにする方法に使用されます。このフィールドで指定された時間以降、要求されたURLが変更されていない場合、エンティティはサーバーから返されません。代わりに、304(変更されていない)応答がメッセージ本文なしで返されます。一般的な構文は次のとおりです。

If-Modified-Since : HTTP-date

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

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

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

If-None-Match

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

If-None-Match : entity-tag

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

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

If-Range

もしレンジリクエストヘッダフィールドは、それが変更された場合のみ、変更されていない場合、欠落している実体の部分、及び全体エンティティを要求するために条件付きGETと共に使用することができます。一般的な構文は次のとおりです。

If-Range : entity-tag | HTTP-date

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

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

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

場合-変更なし-以降

もし非改変-のでリクエストヘッダフィールドは、それが条件付きにする方法に使用されます。一般的な構文は次のとおりです。

If-Unmodified-Since : HTTP-date

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

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

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

マックスフォワード

マックスを転送リクエストヘッダフィールドは、次のインバウンドサーバに要求を転送することができるプロキシまたはゲートウェイの数を制限するTRACEとOPTIONS方法とメカニズムを提供します。一般的な構文は次のとおりです。

Max-Forwards : n

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

Max-Forwards : 5

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

プロキシ認証

プロキシ認証リクエストヘッダフィールドは、クライアントが認証を必要とするプロキシにそれ自体(又はそのユーザ)を識別することを可能にします。一般的な構文は次のとおりです。

Proxy-Authorization : credentials

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

範囲

レンジリクエストヘッダフィールドは、コンテンツの一部の範囲(複数可)は、文書から要求を指定します。一般的な構文は次のとおりです。

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からドキュメントの終わりまでです。

リファラー

リファラーリクエストヘッダフィールドは、クライアントがURLが要求されたリソースのアドレス(URI)を指定することができます。一般的な構文は次のとおりです。

Referer : absoluteURI | relativeURI

以下は簡単な例です。

Referer: http://www.tutorialspoint.org/http/index.htm

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

TE

TEリクエストヘッダフィールドは、拡張かを示す転送コーディング応答して、チャンクにトレーラフィールド受け入れる意志があるか否かを受け入れる意志がある転送コーディングを。一般的な構文は次のとおりです。

TE   : t-codings

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

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

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

ユーザーエージェント

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

User-Agent : product | comment

例:

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

サーバー応答ヘッダー

Accept-Ranges

受け入れ-範囲レスポンスヘッダフィールドは、サーバがリソースの範囲要求の受諾を示すことを可能にします。一般的な構文は次のとおりです。

Accept-Ranges  : range-unit | none

たとえば、バイト範囲の要求を受け入れるサーバーは、

Accept-Ranges: bytes

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

Accept-Ranges: none

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

年齢

年齢レスポンスヘッダフィールドは、応答(またはその再検証)からの経過時間の量の送信者の推定オリジンサーバで生成された搬送します。一般的な構文は次のとおりです。

Age : delta-seconds

経過時間の値は負でない10進整数であり、時間を秒単位で表します。以下は簡単な例です。

Age: 1030

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

ETag

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

ETag :  entity-tag

以下は簡単な例です。

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

ロケーション

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

Location : absoluteURI

以下は簡単な例です。

Location: http://www.tutorialspoint.org/http/index.htm

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

プロキシ認証

プロキシ認証レスポンス・ヘッダー・フィールドは、407(プロキシ認証が必要)応答の一部として含まれなければなりません。一般的な構文は次のとおりです。

Proxy-Authenticate  : challenge

再試行-後

リトライ後レスポンスヘッダフィールドは、サービスを要求しているクライアントに利用できないと予想される時間の長さを示すために503(サービス利用不可)応答と共に使用することができます。一般的な構文は次のとおりです。

Retry-After : HTTP-date | delta-seconds

以下は2つの簡単な例です。

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

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

サーバ

サーバーレスポンスヘッダフィールドは、リクエストを処理するためにオリジンサーバによって使用されているソフトウェアに関する情報が含まれています。一般的な構文は次のとおりです。

Server : product | comment

以下は簡単な例です。

Server: Apache/2.2.14 (Win32)

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

セットクッキー

Set-Cookieレスポンス・ヘッダー・フィールドは、このURLのために保持する情報の名前/値ペアを含んでいます。一般的な構文は次のとおりです。

Set-Cookie: NAME=VALUE; OPTIONS

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

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

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

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

変化する

ヴァリエンティティが複数のソースを有し、したがって、リクエストヘッダ(単数または複数)の指定されたリストに従って変化し得ることをレスポンス・ヘッダー・フィールドを指定します。一般的な構文は次のとおりです。

Vary : field-name

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

Vary: Accept-Language, Accept-Encoding

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

WWW-認証

WWW認証応答ヘッダフィールドは401(不正な)応答メッセージに含まれなければなりません。フィールド値は、Request-URIに適用可能な認証スキームとパラメーターを示す少なくとも1つのチャレンジで構成されます。一般的な構文は次のとおりです。

WWW-Authenticate : challenge

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

WWW-Authenticate: BASIC realm="Admin"

エンティティヘッダー

許可する

許可エンティティヘッダフィールドのリストをリクエストURIによって識別されたリソースによってサポートされるメソッドのセット。一般的な構文は次のとおりです。

Allow : Method

複数のメソッドをコンマで区切って指定できます。以下は簡単な例です。

Allow: GET, HEAD, PUT

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

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

コンテンツ符号化エンティティ-ヘッダフィールドはメディアタイプの修飾子として使用されます。一般的な構文は次のとおりです。

Content-Encoding : content-coding

コンテンツコーディングは、Request-URIによって識別されるエンティティの特性です。以下は簡単な例です。

Content-Encoding: gzip

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

コンテンツ-言語

コンテンツ言語エンティティヘッダフィールドは、同封のエンティティの対象読者の自然言語(複数可)を記述する。一般的な構文は次のとおりです。

Content-Language : language-tag

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

Content-Language: mi, en

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

コンテンツの長さ

Content-Lengthエンティティヘッダフィールドは、HEADメソッドの場合には、受信者に送信されるか、またはオクテットの進数、持っていたに送信されたであろうエンティティボディのサイズは、エンティティボディのサイズを示しますリクエストはGETでした。一般的な構文は次のとおりです。

Content-Length : DIGITS

以下は簡単な例です。

Content-Length: 3495

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

コンテンツ-場所

コンテンツロケーションエンティティヘッダフィールドは、そのエンティティは、要求されたリソースのURIから離れた場所からアクセス可能である場合、メッセージで囲まれたエンティティのリソースの場所を供給するために使用されてもよいです。一般的な構文は次のとおりです。

Content-Location:  absoluteURI | relativeURI

以下は簡単な例です。

Content-Location: http://www.tutorialspoint.org/http/index.htm

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

コンテンツ-MD5

コンテンツ-MD5エンティティヘッダフィールドは、受信するメッセージの完全性をチェックするため、エンティティのMD5ダイジェストを供給するために使用されてもよいです。一般的な構文は次のとおりです。

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

以下は簡単な例です。

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5ダイジェストは、適用されたコンテンツコーディングを含むが、メッセージボディに適用された転送エンコーディングを含まないエンティティボディのコンテンツに基づいて計算されます。

コンテンツ範囲

コンテンツレンジエンティティヘッダフィールドは、完全なエンティティボディに身体部分が適用されるべき場所を指定する部分エンティティボディで送信されます。一般的な構文は次のとおりです。

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エンティティヘッダフィールドは、エンティティボディのメディアタイプが受信者に送信されるか、または、HEADメソッドの場合には、送信されたであろうメディアタイプがGETされリクエストがあった。示し 一般的な構文は次のとおりです。

Content-Type : media-type

次に例を示します。

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

有効期限が切れます

有効期限エンティティヘッダフィールドは、応答が古くなったとみなされた後の日付/時間を与えます。一般的な構文は次のとおりです。

Expires : HTTP-date

次に例を示します。

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

最終更新日

Last-Modifiedエンティティヘッダフィールドは、オリジンサーバがバリアントが最後に変更されたと考えていた日時を示します。一般的な構文は次のとおりです。

Last-Modified: HTTP-date

次に例を示します。

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

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

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

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

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

Cache-control: no-cache

クライアントがHTTPリクエストで使用できる重要なキャッシュリクエストディレクティブは次のとおりです。

SN キャッシュリクエストのディレクティブと説明
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応答で使用できる重要なキャッシュ応答ディレクティブは次のとおりです。

SN キャッシュ応答ディレクティブと説明
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は、ASCII文字セットを使用してインターネット経由でのみ送信できます。ASCII文字セットには、ASCIIセット外の文字が含まれていることがよくあります。したがって、これらの安全でない文字は、% その後に2桁の16進数が続きます。

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

ASCII シンボル 置換
<32   %xxでエンコードします。xxは文字の16進表現です。
32 スペース +または%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
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 バツ バツ
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
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 バツ バツ
121 y y
122 z z
123 {{ %7B
124 | %7C
125 } %7D
126 %7E
127   %7F
> 127   %xxでエンコードします。xxは文字の16進表現です。

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

個人情報の漏えい

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

  • すべての機密情報は、暗号化された形式でサーバー側に保存する必要があります。

  • サーバーの特定のソフトウェアバージョンを明らかにすると、サーバーマシンが、セキュリティホールを含むことがわかっているソフトウェアに対する攻撃に対してより脆弱になる可能性があります。

  • ネットワークファイアウォールを介したポータルとして機能するプロキシは、ファイアウォールの背後にあるホストを識別するヘッダー情報の転送に関して特別な予防措置を講じる必要があります。

  • Fromフィールドで送信される情報は、ユーザーのプライバシーの利益またはサイトのセキュリティポリシーと競合する可能性があるため、ユーザーがフィールドの内容を無効化、有効化、および変更できない限り、送信しないでください。

  • 参照ページがセキュアプロトコルで転送された場合、クライアントは(非セキュア)HTTPリクエストにリファラーヘッダーフィールドを含めないでください。

  • HTTPプロトコルを使用するサービスの作成者は、機密データの送信にGETベースのフォームを使用しないでください。これにより、このデータがRequest-URIにエンコードされるためです。

ファイル名とパス名に基づく攻撃

ドキュメントは、HTTPリクエストによって返されるドキュメントに制限して、サーバー管理者が意図したものだけにする必要があります。

たとえば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムは ..現在のディレクトリレベルより上のディレクトリレベルを示すパスコンポーネントとして。そのようなシステムでは、HTTPサーバーは、HTTPサーバーを介してアクセスすることを目的としたリソース以外のリソースへのアクセスを許可する場合、Request-URIでそのような構成を許可しない必要があります。

DNSスプーフィング

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

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

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

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

認証資格情報

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

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

プロキシとキャッシング

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

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

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

例1

フェッチするHTTPリクエスト hello.htmtutorialspoint.comで実行されているWebサーバーのページ

クライアントのリクエスト

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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

フェッチするHTTPリクエスト t.htmltutorialspoint.comで実行されているWebサーバーに存在しないページ

クライアントのリクエスト

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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: close
   
<!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 /t.html was not found on this server.</p>
</body>
</html>

例3

フェッチするHTTPリクエスト hello.htmtutorialspoint.comで実行されているWebサーバーからのページですが、リクエストが間違ったHTTPバージョンで送信されます。

クライアントのリクエスト

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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: close
   
<!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>

例4

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

クライアントのリクエスト

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.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=tutorialspoint.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>