[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 はメッセージ とその色々な構成要素を含んでいます。
HTTPメッセージ HTTP要求 /HTTP応答 HTTPの版 要求URL HTTPヘッダー 状態符号 転送符号化 HTTPのエラー処理 HTTPにおけるURL HTTP認証 Cookie HTTP CORS Protocol WebDAV [1] 処理モデルは各構成要素の項に説明があります。
HTTP接続 HTTPS HSTS PKP HTTPメッセージ HTTP鯖 対象資源 内容折衝 条件付き要求 範囲要求 同一起源ポリシー [50] プロトコル の拡張点として次のものが存在し、またはかつて提案されていました。プロトコルの版 要求メソッド HTTPヘッダー 状態符号 Upgrade: PEP RFC 2774
状態 [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
[34] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (2014-06-07 01:59:35 +09:00 版) https://tools.ietf.org/html/rfc7230#page-59 [37] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (2014-06-07 01:59:35 +09:00 版) https://tools.ietf.org/html/rfc7230#section-8.6.2 [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 を下位層として使っています。
FTP over HTTP HTCPCP HTCPCP-TEA WebDAV IPP XML-RPC SOAP AtomPub SPARQL LDP OPES UPnP MPEG-DASH AS2 WebFinger OpenID OAuth EST PuSH SSE WebDriver OCSP over HTTP RDAP long polling COMET BOSH Jabber HTTP Polling Certificate Transparency gRPC SCEP Micropub TrackBack Pingback Webmention POX over HTTP 証明書ダウンロード Memento Bayeux PKIX over Secure HTTP HTTPX HELD RID JMAP TZDIST CMC EST DNS-over-HTTPS ICY Icecast YASMIN OpenURL List-Unsubscribe-Post:RESTCONF THTTP SSTP IIIF Solid MMI Web Push protocol HLS JWLの取得プロトコル oEmbed /uri-res/TSP Time over HTTPS IndexNow Common Media Client Data WMS Gmail Actions GraphQL FIPA MTP IndexNow ikachan HTTP Certificate Store Interface [58] HTTP を使って Webアプリケーション の操作を機械的に指示する手段を提供するものを
Web API などと呼びます。多くの Webアプリケーション が JSON 、XML 、
Atom 、application/x-www-form-urlencoded 文書形式 や
OAuth 、基本認証 などの認証 方式と HTTP を組み合わせた API を提供しています。
派生プロトコル [29] 派生, HTTPもどき といっても色々な度合いがありますが...
[41] 輸送路 を変えたものHTTP over SCTP HTTPU HTTPMU SSDP HTTP-DTN S-HTTP
[43] 大きく改変したものHTTP-NG GridHTTP XHTTP Reverse HTTP Bidirectional HTTP
[42] プロトコル の構造を流用したものRTSP SIP MRCP SSTP Q4S ICAP ICE ICY CATP
[40] プロトコル要素 を流用したものWSP HTTP over XMPP FCAST CoAP SPDY Web Sockets HTTP Vocabulary in RDF
[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 となりました。
[79]
1993-11-05 版:
1994-03-07 18:56,
2025-05-16T14:58:09.400Z
https://www.sapmed.ac.jp/satui/std/doc/WWW/http-spec.ps 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 の拡張として定義しました。
IETF WEBDAV Working Group Home Page http://www.ics.uci.edu/~ejw/authoring/ ietf-webdav[15] その他、 IETF では HTTP 派生仕様として RTSP や SIP
や MSRP が標準化されています。
[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
(2009-12-09 08:43:01 +09:00 版)
http://krijnhoetmer.nl/irc-logs/whatwg/20091013
[20] Design Issues for HTTP
(1997-06-06 04:48:52 +09:00 版)
http://www.w3.org/Protocols/DesignIssues.html
[21] Hypertext Transfer Protocol Version 1.x
(2000-09-27 19:46:32 +09:00 版)
http://www.w3.org/Protocols/HTTP/
[22] HTTP - Hypertext Transfer Protocol Overview
(2009-10-26 18:38:01 +09:00 版)
http://www.w3.org/Protocols/
[23] HTTP Problem Statement
(1997-06-06 06:45:05 +09:00 版)
http://www.w3.org/Protocols/HTTP-NG/951005_Problem.html
[24] ( (1993-11-05 09:08:00 +09:00 版))
http://cantor1.mathematik.uni-halle.de/doc/CERN/doc/http-spec.txt
[25] ( (1993-11-12 08:03:00 +09:00 版))
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
( (2012-07-10 14:37:20 +09:00 版))
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.
( (2008-12-02 08:52:00 +09:00 版))
http://html5.org/tools/web-apps-tracker?from=2498&to=2499
[28] crwlr.net - server header information index | beta
( (2014-03-05 09:03:07 +09:00 版))
http://crwlr.net/
[38] httpwg/http-extensions
( (2014-07-30 01:12:42 +09:00 版))
https://github.com/httpwg/http-extensions
[39] Work in Progress
( (2014-08-28 07:23:02 +09:00 版))
https://httpwg.github.io/wip/
[53] draft-aboba-rtp-http-02 - Payload Format for HTTP Encoding in RTP
( (2015-02-02 03:35:25 +09:00 版))
https://tools.ietf.org/html/draft-aboba-rtp-http-02
[59] HTML Standard
(2015-03-05 09:33:40 +09:00 版)
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
(2015-06-07 16:22:49 +09:00 版)
http://tools.ietf.org/html/rfc3205
[71] Wireless Profiled HTTP Version 29-Mar-2001
(2013-09-23 14:21:12 +09:00 版)
http://technical.openmobilealliance.org/tech/affiliates/wap/WAP-229-HTTP-20010329-a.pdf
[72] Hypertext Transport Protocol HTTP/1.1
( (1996-10-21 04:41:52 +09:00 ))
https://www.w3.org/Talks/9608HTTP/
[73] protocol: make normative reference to http (#315)
(andreastt 著, 2016-07-19 23:51:12 +09:00 )
https://github.com/w3c/webdriver/commit/8f75b83f789d0dead1a370e0a90f57cce045c64f