Hypertext Transfer Protocol

Hypertext Transfer Protocol
通信プロトコル
目的 ハイパーテキストなどの転送
開発者
導入 1991年 (33年前) (1991)
派生先 HTTP/2、HTTP/3、WebDAV
OSI階層 アプリケーション層
ポート 80
RFC
  • 共通: RFC 9110, RFC 9111
  • HTTP/1.1: RFC 9112
  • HTTP/2: RFC 9113
  • HTTP/3: RFC 9114
HTTP
主要項目
リクエストメソッド
ヘッダーフィールド（英語版）
ステータスコード
認証方式
セキュリティホール
TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、HTTP）はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである[1]。

概要

[編集]

TCPやQUICはアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、1往復のクライアントリクエスト&サーバーレスポンスという形で通信される、と定めたプロトコルである[1]。

HTTPの発明により、インターネット上でのリソース公開とアクセスが容易になった。クライアントがサーバーとコネクションを確立し1つのHTTPメッセージを書いて送るだけで、サーバー上のリソースがHTTPメッセージとして帰ってくる。ゆえにHTTPで公開されるあらゆるリソースにHTTPという単一の手法でアクセスできるようになった。

HTTPを開発した理由でありかつ現在も広く利用される用途はWorld Wide Webである。WebサーバとWebブラウザはHTTPで主に通信しており、ブラウザからのHTTPメッセージに応答してサーバーがHTMLテキストやJavaScriptコードを送り返し、これをブラウザで表示することでウェブが成立している。

またHTTPはメッセージ形式を定める。基本的な考え方は単純で「何を」「どうして」欲しいのかを伝える。例えばリクエストメッセージ GET /apple.jpg は「apple.jpg 画像を、手に入れたい」を意味する。URLが「何を」に、メソッドが「どうして」に当たる。

World Wide WebにおけるWebページなどのリソースは、Uniform Resource Identifierによって指定される。HTTP を使用してリソースにアクセスするときは、http: が先頭についた URL を使用する。下にURL の例を挙げる。 

http://www.example.co.jp/~test/samples/index.html

最初の HTTP/0.9 ではURLを指定してコンテントをダウンロードするのみの簡単なやりとりだったが、HTTP/1.0 で改良された。

  • リクエストのセマンティクスを指定する、様々なリクエストメソッドが追加された。POSTを使って、アップロード（クライアントからサーバへのデータの転送）が可能になった。
  • NNTPやSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。

HTTP/1.1 では複数データを効率よく転送するための持続的接続や、プロキシの利用なども想定した仕様になった。さらに HTTP/2やHTTP/3が策定された。現在ではHTTPセマンティクスと各バージョンの手続きが分離して定義されている（#規格を参照）。

このほかの点を箇条書きで示す。

歴史

[編集]

イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。

以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。

最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントだったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。

HTTP/0.9

[編集]

1991年に最初にドキュメント化されたバージョン[2]。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。 

GET /index.html

HTTP/1.0

[編集]

1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。

HTTP/1.0のリクエスト
GET /index.html HTTP/1.0

HTTP/1.1

[編集]

1997年1月に RFC 2068 として初版が発表された。その後、3回改訂され、現在はセマンティクス・キャッシングを除く部分がRFC 9112で規定されている。

名前ベースバーチャルホストのため、Hostヘッダーフィールドの規定が追加された。

HTTP/1.1のリクエスト
GET /index.html HTTP/1.1 Host: foo.example.com

HTTP/2

[編集]
→詳細は「HTTP/2」を参照

HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ[3]、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された[4]。

HTTP/3

[編集]
→詳細は「HTTP/3」を参照

HTTP-over-QUIC（hq）としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。[5] IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。[6]

HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと[7]、ヘッドオブラインブロッキング（英語版）を回避するためのヘッダ圧縮の変更（HTTP/3用にQPACKが開発されている）[8]などの差異がある。

Googleが試験的に開発していたプロトコルについては「QUIC」を参照

動作

[編集]

通信の開始

[編集]

他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。

クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。

接続

[編集]

システム間でメッセージをやりとりするには接続を確立させる必要がある。HTTP/0.9～HTTP/1.1およびHTTP/2ではTCPを使用する。

HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があった。これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、1回のTCP接続で、複数のHTTPリクエスト・レスポンスをやり取りする持続的接続がHTTP/1.0の拡張として導入された。その後、HTTP/1.1では、持続的接続がデフォルトとなった。すなわち、何も指定しなければ持続的接続となり、持続的接続を望まなければヘッダーフィールドにConnection: closeを追加する仕様となっている。

→詳細は「HTTPの持続的接続」を参照

パイプライン

[編集]

クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。

→詳細は「HTTPパイプライン」を参照

リクエストメソッド

[編集]

HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドが大部分を占める。

→「en:Request method」も参照
HTTPメソッドの一覧
メソッド HTTP/0.9 HTTP/1.0 HTTP/1.1
GET ○ ○ ○
POST ○ ○
PUT △ ○
HEAD ○ ○
DELETE △ ○
OPTIONS ○
TRACE ○
CONNECT ○
GET
指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。
POST
→「POST (HTTP)（英語版）」も参照
GETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。
PUT
指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。
DELETE
指定したURIのリソースを削除する。
OPTIONS
サーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。
HEAD
GETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。
TRACE
サーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。
CONNECT
TCPトンネルを接続する。暗号化したメッセージをプロキシサーバを経由して転送する際に用いる。当初、ネットスケープコミュニケーションズによって考案されたものがIETFドラフトTunneling TCP based protocols through Web proxy serversとして公開され[9]、RFC 2817 に取り込まれた。その後、RFC 7230 で定義が更新されている[10]。

HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol (HTTP) Method Registry[11]で管理されている。WebDavで使用するものや、 RFC 5789 のPATCHメソッド（英語版）などがある。

サーバの連携

[編集]

バーチャルホスト

[編集]

1つのサーバーで複数のホスト名に対するHTTPリクエストを受け付ける機能である。

インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時はまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しく、ISPのサーバでホスティングをしていた。また、1社ごとに専用サーバを用意するほどのことでもないため、1台のサーバで複数のWebサイトを運用していた。

しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。例えば、ある1台のサーバに foo.example.com と bar.example.com という2つの仮想Webサーバがあり、クライアントは http://foo.example.com/index.html にアクセスしたいとする。この場合はDNSサーバに foo.example.com のIPアドレスを問い合わせ、次にそのIPアドレスを使って該当サーバにアクセスし、GET index.html を要求することになる。しかし同じサーバ上にある bar.example.comもIPアドレスは同じであり、もし両方の仮想サーバに index.html というファイルが存在すれば、クライアントがどちらにアクセスしようとしているのか、判別できない。

対策としてはそれぞれにIPアドレスを付与する方法もあるが、IPv4の資源を無駄にすることになる。この問題を解決するため、HTTP/1.1でHostヘッダーフィールドが追加され、名前ベースバーチャルホストが用いられるようになった。

名前ベースバーチャルホストのため、以下のようにHTTPリクエストでホスト名を指定する。

  • HTTP/1.1: Hostヘッダーフィールドでホスト名を指定する。
  • HTTP/2およびHTTP/3: :authority疑似ヘッダーフィールドでホスト名を指定する。

リダイレクト

[編集]
→「リダイレクト (HTTP) § HTTPリダイレクト」も参照

別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。

クッキー

[編集]
→詳細は「HTTP cookie」を参照

HTTPメッセージ

[編集]

リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。クライアントからリクエストHTTPメッセージを送り、サーバーからレスポンスHTTPメッセージを返す。

HTTPメッセージは以下で構成される[12]。

  • コントロールデータ
  • ヘッダー
  • コンテント
  • トレイラー

なおHTTP/1.1では、コントロールデータをリクエスト行・ステータス行として表現し、コンテントを格納する部分をメッセージボディまたは単にボディと呼ぶ。

ヘッダー・コンテント・トレイラーは空となる場合もある。

下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。

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

GET / HTTP/1.1 Host: www.google.co.jp

この例では、リクエスト行とヘッダーにフィールドが1項目あるのみで、ボディは空でトレーラーも無い。 リクエスト行はメソッド、リクエストターゲット、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。 メソッドはGET、リクエストターゲットは「/」、HTTPバージョンは1.1である。

GETはリソースを取得するためのメソッドであり、リクエストターゲットの「/」はURIのパス部分であってルートリソースを対象にしたリクエストであることを示している。

サーバのレスポンス: 

HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html Set-Cookie: PREF=ID=72c1ca72230dea65:LD=ja:TM=1113132863:LM=1113132863:S=nNO7MIp W2o7Cqeu_; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.co.jp Server: GWS/2.1 Date: Sun, 10 Apr 2005 11:34:23 GMT Connection: Close  <html><head><meta http-equiv="content-type" content="text/html; charset=Shift_JI  S"><title>Google</title><style><!--  ……以下省略 -->

先頭のステータス行はHTTPバージョン、ステータスコード、ステータスメッセージから構成される。 ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。

2行目以降にヘッダフィールドが続く。 さらに空行を挟んで、レスポンスボディとなる。 このレスポンスにもトレーラーは無い。

HTTPヘッダフィールド

[編集]

ヘッダの各要素は

フィールド名: 内容

のペアで構成される。

ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。

なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。 ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。

HTTPヘッダフィールドの一覧

[編集]
リクエストヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Accept クライアントの受け入れ可能コンテンツタイプを示す ○ ○
Accept-Charset クライアントの受け入れ可能文字セットを示す ○ ○
Accept-Encoding クライアントの受け入れ可能文字エンコーディングを示す ○ ○
Accept-Language クライアントの受け入れ可能言語を示す ○ ○
Authorization クライアントの認証情報を示す ○ ○
Cookie クライアントの状態管理情報をサーバに返す
Cookie2 HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる
Expect クライアントがサーバに期待する動作を示す ○
From リクエスト発行者個人の情報を示す。一般的に電子メールアドレスを使用する ○ ○
Host 要求しているオブジェクトがあるホストを示す ○
If-Match if文を用い条件が真の場合のみリクエストを処理するようサーバに要求する ○
If-None-Match If-Matchの逆で条件が真でない場合のみリクエストを処理する要求 ○
If-Range 条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する ○
If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する ○ ○
If-Unmodified-Since If-Modified-Sinceの逆で真でないときのみ実行する ○
Max-Forwards リクエストの中間システム経由数を最大いくつまでかを指定する ○
Proxy-Authorization クライアントがプロキシサーバに対して自身の認証を行う ○
Range オブジェクト全体でなくリソースの一部を要求する ○
Referer リクエストの出所を示す。一般的にはユーザの辿ったWebページのURLが用いられる ○ ○
TE レスポンスの受け入れ可能転送エンコーディングを示す ○
User-Agent クライアントのWebブラウザなどの情報を示す ○ ○
レスポンスヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Accept-Ranges オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す ○
Age オブジェクトの経過時間を秒単位で返す ○
ETag オブジェクトのエンティティタグ値を示す ○
Location オブジェクトの場所を示す ○ ○
Proxy-Authenticate プロキシサーバがクライアントに認証を要求するときに用いる ○
Retry-After リクエストの再試行をいつ行うかをクライアントに通知する ○ ○
Server サーバのベンダー名、バージョン番号を示す ○ ○
Set-Cookie2 サーバがクライアントにCookieを送信するときに用いる
Vary サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す ○
WWW-Authenticate クライアントに対してリクエストの再発行を要求する。認証情報も含まれる ○ ○
一般ヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Cache-Control メッセージの経由する中間キャッシュの動作を指示する ○
Connection 当該の接続に対するオプションを指示する ○
Date メッセージの作成日時を示す ○ ○
Pragma メッセージに関する追加情報を示す ○ ○
Trailer メッセージボディの後に追加のヘッダーが表れることを示す ○
Transfer-Encoding クライアントの転送を目的としたオブジェクトのエンコーディングを示す ○
Upgrade 通信相手に別のプロトコルにアップデートするよう要求する ○
Via プロキシサーバなど中継地点を示す。 ○
Warning メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる ○
エンティティヘッダ
ヘッダ 概要 HTTP/0.9 HTTP/1.0 HTTP/1.1
Allow オブジェクトがサポートするHTTPメソッドを示す ○ ○
Content-Encoding オブジェクトのエンコーディングを示す ○ ○
Content-Language オブジェクトの言語（人間の言語）を示す ○ ○
Content-Length オブジェクトのサイズをバイト単位で示す ○ ○
Content-Location オブジェクトの場所を示す ○
Content-MD5 オブジェクトのメッセージダイジェストを運ぶ △
Content-Range メッセージボディで運ばれるオブジェクトの範囲を示す ○
Content-Type オブジェクトのタイプを示す ○ ○
Expires オブジェクトの有効期限の日時を示す ○ ○
Last-Modified オブジェクトが最後に変更された日時を示す ○ ○
Accept
サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定するリクエストヘッダ。指定できるコンテンツタイプはIANAによって定義されている。
Accept: text/plain; q=0.5, text/html, 	text/x-dvi; q=0.8, text/x-c
上記のようにAcceptヘッダには行をわけて複数のコンテンツタイプを指定できる。上記の例はいずれの4のコンテンツタイプのいずれも受け入れ可能であることを示す。0.5や0.8といった数字は品質係数で0〜1の範囲の数値である。数値の指定がなければ1.0となる。
  • text/plain; q=0.5
  • text/html
  • text/x-dvi; q=0.8
  • text/x-c
Accept-Charset
レスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。
Accept-Charset: UTF-8, *; q=0.8
この例だとクライアントはUTF-8を優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。
Accept-Encoding
クライアントが受信できるメッセージボディのエンコーディングを指定する。
Accept-Encoding: gzip, deflate
この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。
Accept-Encodingで指定可能なエンコーディングは、IANAがHTTP Content Coding Registryとして管理されている[13]。
Accept-Language
レスポンスの言語（人間の言語）に対する優先度を指定する。言語の指定にはIETF言語タグを用いる。書き方は他のAccept-群と変わらず。
Accept-Language: en-gb, en; q=0.8
上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。
Accept-Ranges
Acceptで始まる他のヘッダフィールドと違いレスポンスヘッダである。現在の仕様では2つの指定方法しかない。
Age
リソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。
Allow
Authentication-info
ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ。
Authorization
サーバに対するクライアント自身の認証を行うことが出来る。
Cache-Control
キャッシングの動作を指定するためのマスターヘッダ。
Connection
接続に対するオプションを指定する。その値には以下が使用される。
keep-alive
持続的接続を行う。
close
持続的接続を行わない。
upgrade
他のプロトコルへのアップグレードを希望する。
Content-Encoding
Content-Language
リソースの表現に用いられる言語の明示に使われる。言語の指定はAccept-Languageヘッダと同じ。
Content-Length
Content-Location
Content-MD5
メッセージボディが変更されず宛先に届いたことの保証に用いる。MD5によるハッシュ値をヘッダー値に記載する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変化が生じていないことの保証をしている[14]。RFC 7231で廃止された[15]。
Content-Range
ダウンロードの再開に用いられる。
Content-Type
→「メディアタイプ」も参照
メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。
Content-Type: text/plain; Charset=ISO-8859-4
Cookie
→詳細は「HTTP cookie」を参照
クライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダを付加する。
Cookie: $Version="1"; NAME="VALUE";         $Path="/shopping"; $domain="www.shop.com"+         $Port="80"
$VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。
Cookie2
基本的にCookieヘッダとCookie2ヘッダは別物である。
Date
サーバがメッセージを生成した日時を示す。リソースの更新日時を示すLast-Modifiedヘッダとは別である。
HTTP/1.1では次のような形式を用いる。これはRFC 7231の7.1.1.1. Date/Time Formatsで定義されている。HTTP/1.1の以前の版であるRFC 2616では、日時の形式の定義にRFC 1123を参照していた（内容は同等である）。
Date: Sun, 06, Nov 1994 08:49:37 GMT
HTTP仕様ではレスポンスにDateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。
ETag
主にキャッシングのパフォーマンスを向上する目的で使われる。
Expect
サーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して100 Continueステータスを返すことを期待する場合に使われる。
Expect: 100-continue
サーバが期待に応じられない場合は417 Expectation Failedを返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。
Expires
オブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる。サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。
Expires: Thu, 28 Aug 2010 16:00:00 GMT
Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。
From
リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。
From: user@example.com
Host
主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい（詳細はHTTP#歴史を参照）。
If-Match
ETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。
→「if文」も参照
  1. 利用者：AがHTTPの記事を取得。ETagは1234。
  2. 利用者：BがHTTPの記事を取得。ETagは1234。
  3. 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
  4. 利用者：AがHTTPの記事を編集。ETagは1256になる。
  5. 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
  6. サーバは利用者：Bの書き込みを拒否。
If-Modified-Since
指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。
If-None-Match
If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。
If-Range
クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。
If-Unmodified-Since
If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。
Last-Modified
レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。
Location
サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。
Max-Forwards
プロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。

HTTPステータスコード

[編集]

ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。

→詳細は「HTTPステータスコード」を参照

セキュリティ技術

[編集]

いくつかの観点でセキュリティに関する追加機能が存在する。

HTTPS

[編集]
→詳細は「HTTPS」を参照

セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。

HTTP認証

[編集]
→詳細は「HTTP認証」を参照

HTTPの中で認証を行う仕組みが用意されている。

Basic認証

[編集]

HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる[16]。平文で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。

→詳細は「Basic認証」を参照

Digest認証

[編集]
→詳細は「Digest認証」を参照

規格

[編集]

HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。

セマンティクス キャッシュ 手続き
HTTP/1.1 RFC 9110 RFC 9111 RFC 9112
HTTP/2 RFC 9113
HTTP/3 RFC 9114

歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン（v1.1, v2, v3）が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている[17]。

派生・拡張プロトコル

[編集]

HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。

なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。

脚注

[編集]
[脚注の使い方]
  1. ^ a b "The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols ... HTTP is a stateless request/response protocol for exchanging 'messages' across a connection." RFC 9110.
  2. ^ The HTTP Protocol As Implemented In W3
  3. ^ Sebastian Anthony (2012年3月28日). “S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0”. ExtremeTech. 2014年9月23日閲覧。
  4. ^ Jerome Louvel (2011年10月6日). “Can the rise of SPDY threaten HTTP?”. Restlet. 2014年9月23日閲覧。
  5. ^ “Gigazine『UDPベースの「HTTP-over-QUIC」が新HTTPバージョン「HTTP/3」に名称変更される』”. GIGAZINE (2018年11月14日). 2018年11月14日閲覧。
  6. ^ IETF Meetingの資料スライド
  7. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “後述のストリームの管理がQUICレイヤに移り、それにあわせフレームの変更やQUICストリームの利用方法の定義”
  8. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “ヘッドオブラインブロッキング避けるために、HPACKをQUIC用に改良したQPACKを用いる”
  9. ^ “RFC 2817 Upgrading to TLS Within HTTP/1.1” (2000年5月). 2019年4月26日閲覧。 “The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy servers", by Ari Luotonen of Netscape Communications Corporation.”
  10. ^ “RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing” (2014年6月). 2019年4月26日閲覧。 “This specification also updates the use of CONNECT to establish a tunnel, previously defined in RFC 2817, and defines the "https" URI scheme that was described informally in RFC 2818.”
  11. ^ Hypertext Transfer Protocol (HTTP) Method Registry
  12. ^ RFC 9110, 6. Message Abstraction
  13. ^ HTTP Content Coding Registry
  14. ^ “RFC 1864 The Content-MD5 Header Field” (英語). Internet Engineering Task Force (October 1995). 2021年1月30日閲覧。 “This document specifies a data integrity service that protects data from accidental modification while in transit from the sender to the recipient.”
  15. ^ “RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content” (英語). Internet Engineering Task Force (June 2014). 2021年1月30日閲覧。 “The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.”
  16. ^ 『HTTPプロトコル―セキュア&スケーラブルなWeb開発』 Stephen Thomas 著、葛西 重夫 訳、ソフトバンクパブリッシング[要ページ番号]
  17. ^ “JPNIC News & Views vol.1647【臨時号】第103回IETF報告 [第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3への改称～”. 日本ネットワークインフォメーションセンター (2018年12月13日). 2021年6月28日閲覧。

関連項目

[編集]
ウィクショナリーにHTTPの項目があります。

外部リンク

[編集]

以下は旧式であり非推奨となった仕様

その他

背景
サブトピック
アプリケーション
関連項目
標準
文法とサポート技術
スキーム、オントロジー、ルール
セマンティック注釈
共通語彙
マイクロフォーマット語彙
カテゴリ カテゴリ
公式
非公式
プロトコル一覧（英語版）
サーバサイド
プロトコル
APIs
トピックス
クライアントサイド
Browser APIs
Web API（英語版）
W3C
クロノス
その他
トピックス
関連項目
「https://ja.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=102310143」から取得