Hypertext Transfer Protocol
通信プロトコル | |
目的 | ハイパーテキストなどの転送 |
---|---|
開発者 | |
導入 | 1991年 |
派生先 | HTTP/2、HTTP/3、WebDAV |
OSI階層 | アプリケーション層 |
ポート | 80 |
RFC |
HTTP |
---|
主要項目 |
リクエストメソッド |
ヘッダーフィールド |
ステータスコード |
認証方式 |
セキュリティホール |
TCP/IP群 |
---|
アプリケーション層 |
|
トランスポート層 |
カテゴリ |
インターネット層 |
カテゴリ |
リンク層 |
カテゴリ |
Hypertext Transfer Protocol(ハイパーテキスト・トランスファー・プロトコル、HTTP)はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである[1]。
概要
[編集]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
[編集]- HTTP/1.0のリクエスト
-
GET /index.html HTTP/1.0
- HTTP/1.1のリクエスト
-
GET /index.html HTTP/1.1 Host: foo.example.com
HTTP/1.1
[編集]HTTP/2
[編集]HTTP/3
[編集]HTTP-over-QUIC(hq)としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。[5] IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。[6]
HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと[7]、ヘッドオブラインブロッキングを回避するためのヘッダ圧縮の変更(HTTP/3用にQPACKが開発されている)[8]などの差異がある。
動作
[編集]通信の開始
[編集]他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。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では8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドが大部分を占める。
メソッド | 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疑似ヘッダーフィールドでホスト名を指定する。
リダイレクト
[編集]別の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
、使用候補言語を表すAc
cept-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
ヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDa
te
ヘッダは返らない。 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文」も参照(一)利用者‥AがHTTPの記事を取得。ETag
は1234。 (二)利用者‥BがHTTPの記事を取得。ETag
は1234。 (三)利用者‥AがHTTPのETag
を再度取得。先ほど取得したETa
g: 1234
と現在のETag: 1234
が一致。 (四)利用者‥AがHTTPの記事を編集。ETag
は1256になる。 (五)利用者‥BがHTTPのETagを再度取得。先ほど取得したETa
g
と現在のETagはマッチせず。 (六)サーバは利用者‥Bの書き込みを拒否。 If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。 If-None-MatchIf-Match
の逆で、ETagが一致しない場合のみの実行を要求する。 If-Range クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。 If-Unmodified-SinceIf-Modified-Since
の逆で、指定時刻以降に変更がない場合のみの実行を要求する。 Last-Modified レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のI
f-Modified-Since
ヘッダと組み合わせることで、効率的な通信が可能になる。 Location サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことができる。Content-Location
ヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。 Max-Forwards プロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTI
ON
メソッドや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の構文を元とするプロトコルなどが存在する。以下はその一例である。 ●WebDAV: HTTP上でファイル転送を実現するプロトコル。 ●WebSocket: 双方向通信プロトコル。 ●Internet Printing Protocol (IPP): プリンタの制御と印刷データの伝送を行うプロトコル。 ●UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。 ●Hyper Text Coffee Pot Control Protocol (HTCPCP): エイプリルフールのジョーク。コーヒーポットの制御機能を有するプロトコル。 なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。脚注
[編集](一)^ ab"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. (二)^ The HTTP Protocol As Implemented In W3 (三)^ Sebastian Anthony (2012年3月28日). “S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0”. ExtremeTech. 2014年9月23日閲覧。 (四)^ Jerome Louvel (2011年10月6日). “Can the rise of SPDY threaten HTTP?”. Restlet. 2014年9月23日閲覧。 (五)^ “Gigazine﹃UDPベースの﹁HTTP-over-QUIC﹂が新HTTPバージョン﹁HTTP/3﹂に名称変更される﹄”. GIGAZINE (2018年11月14日). 2018年11月14日閲覧。 (六)^ IETF Meetingの資料スライド (七)^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “後述のストリームの管理がQUICレイヤに移り、それにあわせフレームの変更やQUICストリームの利用方法の定義” (八)^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “ヘッドオブラインブロッキング避けるために、HPACKをQUIC用に改良したQPACKを用いる” (九)^ “RFC [https://datatracker.ietf.org/doc/html/rfc2817 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.” (十)^ “RFC [https://datatracker.ietf.org/doc/html/rfc7230 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 [https://datatracker.ietf.org/doc/html/rfc1864 1864 The Content-MD5 Header Field]” (英語). Internet Engineering Task Force (1995年10月). 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 [https://datatracker.ietf.org/doc/html/rfc7231 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]” (英語). Internet Engineering Task Force (2014年6月). 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/2
- HTTPステータスコード
- FTP
- WebDAV
- Webサーバ
- ウェブブラウザ
- アプリケーションサーバ
- Representational State Transfer (REST)
- HTTPヘッダ・インジェクション
- Hyper Text Coffee Pot Control Protocol
- バーチャルホスト
外部リンク
[編集]- RFC 9110 - HTTP Semantics
- RFC 9111 - HTTP Caching
- RFC 9112 - HTTP/1.1
- RFC 9113 - HTTP/2
- RFC 9114 - HTTP/3
- RFC 9205 - Building Protocols with HTTP
- HTTP に基づくプロトコルの築き方(非公式な日本語訳)
以下は旧式であり非推奨となった仕様
- RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
- RFC7540 日本語訳(非公式)
- RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching
- RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication
- RFC 2818 - HTTP Over TLS
- HTTP Over TLS(IPAによる非公式な日本語訳)
- RFC 2817 - Upgrading to TLS Within HTTP/1.1
- RFC 2616 - HTTP/1.1(RFC 2068の改訂版,RFC 7230 から RFC 7235 によって obsolete)
- RFC 2068 - HTTP/1.1(初版,RFC 2616 によって obsolete)
- TS X 0085:2004 - ハイパテキスト転送プロトコル HTTP/1.1 日本標準仕様書(TS X 0085:2004)
- RFC 1945 - HTTP/1.0
- The HTTP Protocol As Implemented In W3 - HTTP/0.9
その他