HTTPもどき

HTTP (Web)

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

呼称

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

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

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

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

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

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

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

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

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

[52] PEPHTTP/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.1HTTP/2 ではこれが標準機能となっています。

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

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

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

プロトコル HTTP

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

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

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

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

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

REST との関係

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

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

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

URL

[56] HTTPURL については、 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アプリケーションJSONXMLAtomapplication/x-www-form-urlencoded などの文書形式OAuth基本認証などの認証方式と HTTP を組み合わせた API を提供しています。

派生プロトコル

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

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

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

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

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

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


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

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

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

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

API

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

人物

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

歴史

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

標準化

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

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

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

[15] その他、 IETF では HTTP 派生仕様として RTSPSIPMSRP が標準化されています。

[2] 90年代末に HTTP の新しい版として HTTP-NG が検討されていましたが、 失敗に終わりました。

HTTP-NG を参照。

[16] 2008年頃には HTTP/1.1 仕様の改訂の機運が高まり、 ietf-httpbis WG が設置されています。

[17] HTTP の標準化は基本的に IETF で行われていますが、歴史的経緯により W3C が積極的に関わっています。最近では HTML5 機能などに関して WHATWG 界隈での活動も活発になっています。

メモ

[19] IRC logs: freenode / #whatwg / 20091013 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20091013

[20] Design Issues for HTTP ( 版) http://www.w3.org/Protocols/DesignIssues.html

[21] Hypertext Transfer Protocol Version 1.x ( 版) http://www.w3.org/Protocols/HTTP/

[22] HTTP - Hypertext Transfer Protocol Overview ( 版) http://www.w3.org/Protocols/

[23] HTTP Problem Statement ( 版) http://www.w3.org/Protocols/HTTP-NG/951005_Problem.html

[24] ( ( 版)) http://cantor1.mathematik.uni-halle.de/doc/CERN/doc/http-spec.txt

[25] ( ( 版)) http://cantor1.mathematik.uni-halle.de/doc/CERN/doc/draft-ietf-iiir-http-00.txt

[26] Information on http://cantor1.mathematik.uni-halle.de/doc/CERN/doc/draft-ietf-iiir-http-00.txt ( ( 版)) http://suika.fam.cx/gate/2007/schema/schema/536186f16bc0128d84e7690b94f18e92/prop.html

[27] Web Applications 1.0 r2499 Always put javascript: into the online whitelist. Make some comments about HTML and HTTPS security. Vaguely define 'or equivalent' for HTTP concepts. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=2498&to=2499

[28] crwlr.net - server header information index | beta ( ( 版)) http://crwlr.net/

[38] httpwg/http-extensions ( ( 版)) https://github.com/httpwg/http-extensions

[39] Work in Progress ( ( 版)) https://httpwg.github.io/wip/

[53] draft-aboba-rtp-http-02 - Payload Format for HTTP Encoding in RTP ( ( 版)) https://tools.ietf.org/html/draft-aboba-rtp-http-02

[59] HTML Standard ( 版) https://html.spec.whatwg.org/#encrypted-http-and-related-security-concerns

Anything in this specification that refers to HTTP also applies to HTTP-over-TLS, as represented by URLs using the https: scheme.

[64] RFC 3205 - On the use of HTTP as a Substrate for Other Protocols ( 版) http://tools.ietf.org/html/rfc3205

[71] Wireless Profiled HTTP Version 29-Mar-2001 ( 版) http://technical.openmobilealliance.org/tech/affiliates/wap/WAP-229-HTTP-20010329-a.pdf

[72] Hypertext Transport Protocol HTTP/1.1 ( ()) https://www.w3.org/Talks/9608HTTP/

[73] protocol: make normative reference to http (#315) (andreastt著, ) https://github.com/w3c/webdriver/commit/8f75b83f789d0dead1a370e0a90f57cce045c64f