HTTP (Web)

[7] HTTP (エイチティーティーピー) (Hypertext Transfer Protocol) は、 World Wide Web で用いられているネットワークプロトコル (転送プロトコル) です。元々はハイパーテキストの転送のためのクライアント鯖型のアプリケーション層プロトコルでしたが、現在ではハイパーテキストに限らず様々なデータの転送に用いられています。インターネット技術を流用したシステムではセッション層 (あるいはオーバーレイ・ネットワーク層のプロトコルであるかのように用いられることすらあります。

呼称

[69] RFC は HTTP を「Hypertext Transfer Protocol」の略と説明しています。

[70] HTML の展開形は歴史的に「Hypertext」と「HyperText」が混在していました。

[8] HTTP protocol と書くのは変だと思うけど、仕様書 (例えば RFC 2616) も使ってるしなー。

版

[9] HTTP には HTTP/0.9、HTTP/1.0、HTTP/1.1、HTTP/2 の4つの版があります。

[10] 現実に Web で用いられている鯖やクライアント (HTTP では通常利用者エージェント (UA) と呼ばれます。) はこのうち1つ以上に対応しています (ほとんどの場合、最低でも HTTP/1.0 に対応しています)。ただし HTTP は非常に様々な機能を含んだ膨大な仕様で、そのうちのどの部分に対応しているかは実装により異なります。

[11] HTTP/0.9 は HTTP/1.x と互換性がありません。 HTTP/1.0 と HTTP/1.1 はメッセージのレベルでの互換性がありますが、 TCP 接続 (コネクション) の利用方法が異なります (HTTP/1.1 の方が高機能です)。 HTTP/2 は HTTP/1.1 以下と直接的な互換性はありませんが、HTTP/2 におけるメッセージの意味は HTTP/1.1 の定義をそのまま使っています。

[30] 仕様書としては、 HTTP/0.9 と HTTP/1.0 が RFC 1945 に記述されていますが、その後放置されています。 HTTP/1.1 は RFC 7230 などに記述されています。 HTTP/2 は RFC 7540 などで定義されています。詳しくはそれぞれの項を参照してください。

[60] サーバーによっては HTTP/1.0 のみや HTTP/1.0 と HTTP/1.1 のみ、あるいは HTTP/1.1 以下のみに対応するものがあります。従って、これらの版のすべてに対応できないクライアントは、 Web互換ではありません。

[61] クライアントにも HTTP/1.0 のみや HTTP/1.0 と HTTP/1.1 のみ、あるいは HTTP/1.1 以下しか対応しないものもあります。 HTTP/2 のみしか実装しないサーバーは、 Web互換ではありません。

[52] PEP が HTTP/1.2 を名乗っていましたが頓挫し、 HTTP/1.1 の拡張として RFC 2774 になりましたが、結局広く受け入れられることはありませんでした。

[3] HTTPの版も参照。

プロトコルの構成要素

[32] HTTP には色々な役割のプログラムが関与します。

[31] HTTP はメッセージとその色々な構成要素を含んでいます。

[1] 処理モデルは各構成要素の項に説明があります。

[50] プロトコルの拡張点として次のものが存在し、またはかつて提案されていました。

状態

[44] しばしば HTTP は“状態を持たない”と説明されます。 HTTP によるクライアントと鯖の通信は要求と応答の組が1単位となっており、複数の要求と応答の組同士は直接影響しあわないという意味で、 HTTP は状態を持たないプロトコルです。

[45] 他のアプリケーション層プロトコル、例えば SMTP では HELO、認証、送受信者の指定、本文の送信といった複数の命令のやり取りの組み合わせがクライアントと鯖の間で発生します。また IRC は認証の後長時間接続を維持した状態で、適宜命令等のやり取りが発生します。これらプロトコルの“状態”をクライアントと鯖が保持する必要があるプロトコルに対して、 HTTP/1 はプロトコルもその実装も非常に簡潔となっています。

[46] しかしながら、当然ながらクライアントも鯖も、ある要求を送受信しはじめてからそれに対する応答を送受信し終えるまで、その要求と応答に関する“状態”を保持し続ける必要はあります。 1xx 応答を使う場合や multipart/x-mixed-replace を使う場合、 COMET の場合など、より複雑な状況も存在しています。 HTTP/2 ではこれがストリームなる明示的な状態の元で管理されています。

[47] また持続的接続を使う場合には、要求と応答の組を超えてある種の“状態”を接続単位で維持し続けることになります。 HTTP/1.1 と HTTP/2 ではこれが標準機能となっています。

[48] ただし、その場合でも接続とそれに含まれる要求・応答は互いに独立していて、 (接続を継続するか閉じるかの判断以外には) 相互に影響を与えることはありません。例えば最初の要求と応答でHTTP認証を通過したかどうかと、その次の要求と応答が認められるかどうかは無関係となっています。

[49] よりマクロに、HTTP を使うシステム全体として見た時には、様々な“状態” を鯖やクライアントが管理していることがあります。

HTTPキャッシュが使われることがあります。
串が使われることがあります。
TLS session resumption を使う場合、クライアントと鯖はその情報を保持することとなります。
HSTS や PKP を使う場合、利用者エージェントはその状態を保持することとなります。
SDCH を使う場合、クライアントは辞書を保持する必要があるかもしれません。
Cookie が使われる場合、利用者エージェントはその値を保持することとなります。
その他起源鯖や利用者エージェント、あるいはそれらで動作する Webアプリケーションは様々な状態を保持することがあります。

[54] そのような状態を HTTP 上で実装することは好ましくないと考える人もいます。例えば Cookie は HTTP の状態を持たない性質を破壊する不適切な技術と考える人もいます。しかしそのような考え方はあまり現実的ではなく、ほとんど支持されていません。

プロトコル `HTTP`

[33] protocol の値 HTTP は、HTTP を表すプロトコル名として定義されています >>34, >>37。

[35] HTTPの版でも、この名前が使われています。

[36] しかし Upgrade: における処理モデルは明記されていません。 HTTP/1.1 で Upgrade: HTTP/1.1 と指定されたときや、 HTTP/0.9 や HTTP/1.0 や HTTP/2.0 を指定した時にどうなるべきかは明記されていません。

[63] 本プロトコル名は HTTP/2 では使われていません。

HTTP/2 は h2 というより短い名前を使っています。

REST との関係

[18] HTTP を含む Web は REST 体系様式の1実現値であると HTTP や REST の考案者は主張しています。

[51] 実際には HTTP は非 REST 的な使われ方をすることもよくあります。またアプリケーションの HTTP の使い方を「REST API」や「REST ベース」などと修飾することが良くありますが、その意味するところは文脈により様々で、バズワードの類と理解する方が正しいかもしれません。

[65] バズワードとしての REST による HTTP の利用方法については、 REST の項を参照してください。

URL

[56] HTTP の URL については、 HTTPにおけるURLを参照。

下位層プロトコル

[55] HTTP の下位層として用いられるネットワークプロトコルについては、 HTTP接続や HTTPS を参照。

素の HTTP と HTTPS

[66] HTTP は歴史的には TCP/IP 上で用いられてきました。

[67] TLS (SSL) 上で HTTP を使う HTTPS は、90年代から存在していましたが、決済など安全性が特に重要な場面でのみ限定的に用いられていました。しかし10年代に入って Web のセキュリティーが特に深刻な問題と認識されるようになり、徐々に HTTPS への移行が進んでいます。

[68] TLS を使わない素の HTTP は、原則として用いるべきではありません。 HTTPS を使うことを基本とするべきです。

HTTP の上に構築されたプロトコル

[4] 色々なプロトコルが HTTP を下位層として使っています。

[58] HTTP を使って Webアプリケーションの操作を機械的に指示する手段を提供するものを Web API などと呼びます。多くの Webアプリケーションが JSON、XML、 Atom、application/x-www-form-urlencoded などの文書形式や OAuth、基本認証などの認証方式と HTTP を組み合わせた API を提供しています。

派生プロトコル

[29] 派生, HTTPもどきといっても色々な度合いがありますが...

[41] 輸送路を変えたもの

[43] 大きく改変したもの

[42] プロトコルの構造を流用したもの

[40] プロトコル要素を流用したもの

[57] HTTP は Web を代表するプロトコルであり、仕様上の (そして多くの実装における) データ構造は HTTP 以外も HTTP に基づく形で表されます。 HTML Standard は or equivalent のような形でこれを表現しています。 Fetch Standard は要求や応答などの HTTP に由来する内部データ構造を規定しています。 Fetch の API や XHR を通じて著者もこうした HTTP “風” API にアクセスできます。

[75] なんでこんなに HTTPもどきが作られたのか、今から考えると不思議だけど、当時の時代の雰囲気、一過性のブームみたいなものだと思うしかないなあ。

[76] 似せるなら似せるでもっと似せれば実装を共通化できるとか同じサーバーで同時提供できるとかメリットが出てくるはずなんだけど。でもそうなるとHTTPそのものを使えばええやんって話にもなるし、新しいプロトコルを作ったぞ新製品だぞすごいんだぞ感みたいなのあんまりでないから、マーケティング的に(商品売る的な意味でも研究開発部門から会社経営層へのアピール的な意味でも)見劣りしちゃうとかの事情もありそうやね。

[77] HTTP に限ったことではなく、同時期に HTML に似せたHTMLもどきが大量に出てきたし (これは応用ごとに必要な語彙が違ってくるので意味はある(こともある))、少し前の時代にはインターネットメールメッセージもどきがたくさん出てきてたし(HTTPもその1つ)、あるいはSMTPもどきみたいなのもたくさんあるし、新しい技術が流行ったら真似して似たようなのを作るというのはわりと普遍的な考え方なのかもしれない。と思うけど最近はそういうのあんまりないなあ。ベンダー中立のプロトコルが流行る、っていうのがあんまりない時代になってしまったからか?

[78] 似て非なるのがたくさんある、という状況は初期学習を容易にする(とっつきやすくなる)という大きなメリットがある反面、他の似たものに引っ張られて正しい理解が深まらないとか、なんとなくで済ませられるので正確な仕様が出てこなくなるとか、元の仕様の改正にもどきの方が追随できなくなって似てるが似てたになってメリットがなくなるとか、そういうデメリットはいろいろある。

API

[62] HTTP の API については、 HTTPサーバーやHTTPクライアントを参照。

人物

[74] HTTP の開発に大きく関わった人々:

歴史

[6] 初期の HTTP 仕様案 (HTTP92) >>5

[5] HTTP: A protocol for networked information http://www.w3.org/Protocols/HTTP/HTTP2.html

2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT=32176 bytes) (Status: EXPERIMENTAL)

2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake, C. Smith. September 2000. (Format: TXT=16168 bytes) (Status: PROPOSED STANDARD)
RFC2936 HTTP MIME Type Handler Detection. D. Eastlake, C. Smith, D. Soroka. September 2000. (Format: TXT=25238 bytes) (Status: INFORMATIONAL)
2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT PRACTICE)
3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT=57117 bytes) (Status: INFORMATIONAL)
3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning). G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. March 2002. (Format: TXT=245514 bytes) (Status: PROPOSED STANDARD)
Common HTTP Implementation Problems http://www.w3.org/TR/chips/
- HTTP (及び隣接する URI, HTML の一部) についてのチェック集。快適な WWW 生活(謎)のために最低限必要なサーバーの配慮をまとめたメモ。 (HTML UA でいう WAI みたいなものかな。)
- いい仕事してますね、 W3C。
Common User Agent Problems http://www.w3.org/TR/cuap
- こっちは UA の視点から見た HTTP (など) の実装上の問題点。

標準化

[12] HTTP は元々 TimBL により考案され、 CERN を中心とする WWW プロジェクトにより発展させられてきましたが、 IETF に HTTP WG (ietf-http) が設けられてからは主にそこで標準化が進められてきました。

[13] IETF HTTP WG は当時の実装の大枠を反映して HTTP/0.9 と HTTP/1.0 を規定した RFC 1945 を情報提供RFC とした後、改良を加えた新版 HTTP/1.1 を提案標準 RFC 2068 として発行しました。 RFC 2068 は更に改訂されて原案標準 RFC 2616、RFC 2617 となりました。

IETF - Hypertext Transfer Protocol (HTTP) Working Group http://ftp.ics.uci.edu/pub/ietf/http/ (ietf-http)
↑この ietf-http の頁は RFC になっている I-D がまだのように載ってたり、古い内容のままですね。 (ietf-http 閉鎖よりまだ前なのかな?)
HTTP - Hypertext Transfer Protocol Overview http://www.w3.org/Protocols/

[14] HTTP については中核仕様の他に様々な拡張・派生仕様が策定されました。例えば IETF WebDAV WG (ietf-webdav) は HTTP をストレージ的に利用可能な WebDAV 仕様を HTTP の拡張として定義しました。