[7] [DFN@en[[RUBY[[[HTTP]]][エイチティーティーピー]]]] ([DFN@en[[[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]] で用いられている[[鯖]]や[[クライアント]] [WEAK[([[HTTP]] では通常[[利用者エージェント]] ([[UA]]) と呼ばれます。)]] はこのうち1つ以上に対応しています [WEAK[(ほとんどの場合、最低でも [[HTTP/1.0]] に対応しています)]]。 ただし [[HTTP]] は非常に様々な機能を含んだ膨大な仕様で、 そのうちのどの部分に対応しているかは実装により異なります。 [11] [[HTTP/0.9]] は [[HTTP/1.[VAR[x]]]] と互換性がありません。 [[HTTP/1.0]] と [[HTTP/1.1]] は[[メッセージ]]のレベルでの互換性がありますが、 [[TCP]] [RUBY[[[接続]]]@en[[[コネクション]]]]の利用方法が異なります [WEAK[([[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互換]]ではありません。 [HISTORY[ [52] [[PEP]] が [[HTTP/1.2]] を名乗っていましたが頓挫し、 [[HTTP/1.1]] の拡張として [[RFC 2774]] になりましたが、結局広く受け入れられることはありませんでした。 ]HISTORY] ;; [3] [[HTTPの版]]も参照。 * プロトコルの構成要素 [32] [[HTTP]] には色々な役割のプログラムが関与します。 [FIG(list short)[ - [[鯖]] -- [[起源鯖]] - [[クライアント]] -- [[利用者エージェント]] - [[中間器]] -- [[串]] -- [[逆串]] -- [[トンネル]] - [[送信者]]/[[受信者]] - [[上流]]/[[下流]] - [[内向き]]/[[外向き]] - [[末端対末端]]/[[ホップ毎]] - [[キャッシュ]] ]FIG] [31] [[HTTP]] は[[メッセージ]]とその色々な構成要素を含んでいます。 [FIG(short list)[ - [[HTTPメッセージ]] -- [[HTTP要求]]/[[HTTP応答]] -- [[HTTPの版]] -- [[要求URL]] -- [[HTTPヘッダー]] -- [[状態符号]] -- [[転送符号化]] - [[HTTPのエラー処理]] - [[HTTPにおけるURL]] -- [CODE(URI)@en[[[http:]]]] -- [CODE(URI)@en[[[https:]]]] - [[HTTP認証]] - [[Cookie]] - [[HTTP CORS Protocol]] - [[WebDAV]] ]FIG] [1] 処理モデルは各構成要素の項に説明があります。 [FIG(short list)[ - [[HTTP接続]] - [[HTTPS]] - [[HSTS]] - [[PKP]] - [[HTTPメッセージ]] - [[HTTP鯖]] - [[対象資源]] - [[内容折衝]] - [[条件付き要求]] - [[範囲要求]] - [[同一起源ポリシー]] ]FIG] [50] [[プロトコル]]の拡張点として次のものが存在し、またはかつて提案されていました。 [FIG(short list)[ - [[プロトコルの版]] - [[要求メソッド]] - [[HTTPヘッダー]] - [[状態符号]] - [CODE(HTTP)@en[[[Upgrade:]]]] - [[PEP]] - [[RFC 2774]] ]FIG] * 状態 [44] しばしば [[HTTP]] は“状態を持たない”と説明されます。 [[HTTP]] による[[クライアント]]と[[鯖]]の通信は[[要求]]と[[応答]]の組が1単位となっており、 複数の[[要求]]と[[応答]]の組同士は直接影響しあわないという意味で、 [[HTTP]] は状態を持たない[[プロトコル]]です。 ;; [45] 他の[[アプリケーション層プロトコル]]、例えば [[SMTP]] では [CODE[[[HELO]]]]、 [[認証]]、送受信者の指定、本文の送信といった複数の[[命令]]のやり取りの組み合わせが[[クライアント]]と[[鯖]]の間で発生します。また [[IRC]] は[[認証]]の後長時間[[接続]]を維持した状態で、 適宜[[命令]]等のやり取りが発生します。これら[[プロトコル]]の“状態”を[[クライアント]]と[[鯖]]が保持する必要がある[[プロトコル]]に対して、 [[HTTP/1]] は[[プロトコル]]もその実装も非常に簡潔となっています。 [46] しかしながら、当然ながら[[クライアント]]も[[鯖]]も、ある[[要求]]を送受信しはじめてからそれに対する[[応答]]を送受信し終えるまで、 その[[要求]]と[[応答]]に関する“状態”を保持し続ける必要はあります。 [CODE(HTTP)[[[1xx]]]] [[応答]]を使う場合や [CODE(MIME)@en[[[multipart/x-mixed-replace]]]] を使う場合、 [[COMET]] の場合など、より複雑な状況も存在しています。 [[HTTP/2]] ではこれが[[ストリーム]]なる明示的な状態の元で管理されています。 [47] また[[持続的接続]]を使う場合には、[[要求]]と[[応答]]の組を超えてある種の“状態”を[[接続]]単位で維持し続けることになります。 [[HTTP/1.1]] と [[HTTP/2]] ではこれが標準機能となっています。 ;; [48] ただし、その場合でも[[接続]]とそれに含まれる[[要求]]・[[応答]]は互いに独立していて、 ([[接続]]を継続するか閉じるかの判断以外には) 相互に影響を与えることはありません。 例えば最初の[[要求]]と[[応答]]で[[HTTP認証]]を通過したかどうかと、 その次の[[要求]]と[[応答]]が認められるかどうかは無関係となっています。 [49] よりマクロに、[[HTTP]] を使うシステム全体として見た時には、様々な“状態” を[[鯖]]や[[クライアント]]が管理していることがあります。 [FIG(list)[ - [[HTTPキャッシュ]]が使われることがあります。 - [[串]]が使われることがあります。 - [[TLS session resumption]] を使う場合、[[クライアント]]と[[鯖]]はその情報を保持することとなります。 - [[HSTS]] や [[PKP]] を使う場合、[[利用者エージェント]]はその状態を保持することとなります。 - [[SDCH]] を使う場合、[[クライアント]]は辞書を保持する必要があるかもしれません。 - [[Cookie]] が使われる場合、[[利用者エージェント]]はその値を保持することとなります。 - その他[[起源鯖]]や[[利用者エージェント]]、あるいはそれらで動作する [[Webアプリケーション]]は様々な状態を保持することがあります。 ]FIG] [54] そのような状態を [[HTTP]] 上で実装することは好ましくないと考える人もいます。 例えば [[Cookie]] は [[HTTP]] の状態を持たない性質を破壊する不適切な技術と考える人もいます。 しかしそのような考え方はあまり現実的ではなく、ほとんど支持されていません。 * プロトコル [CODE(HTTP)@en[HTTP]] [33] [CODE(ABNF)@en[[[protocol]]]] の値 [DFN[[CODE(HTTP)@en[[[HTTP]]]]]] は、[[HTTP]] を表す[[プロトコル名]]として定義されています [SRC[>>34, >>37]]。 [REFS[ - [34] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [37] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ]REFS] [35] [[HTTPの版]]でも、この名前が使われています。 [36] しかし [CODE(HTTP)@en[[[Upgrade:]]]] における処理モデルは明記されていません。 [[HTTP/1.1]] で [CODE(HTTP)@en[[[Upgrade:]] [[HTTP/1.1]]]] と指定されたときや、 [[HTTP/0.9]] や [[HTTP/1.0]] や [[HTTP/2.0]] を指定した時にどうなるべきかは明記されていません。 [63] 本[[プロトコル]]名は [[HTTP/2]] では使われていません。 ;; [[HTTP/2]] は [CODE[[[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]] を下位層として使っています。 [FIG(short list)[ - [[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]] - [CODE(822)[List-Unsubscribe-Post:]] - [[RESTCONF]] - [[THTTP]] - [[SSTP]] - [[IIIF]] - [[Solid]] - [[MMI]] - [[Web Push protocol]] - [[HLS]] - [[JWLの取得プロトコル]] - [[oEmbed]] - [CODE[/uri-res/]] - [[TSP]] - [[Time over HTTPS]] - [[IndexNow]] - [[Common Media Client Data]] - [[WMS]] - [[Gmail Actions]] - [[GraphQL]] - [[FIPA MTP]] - [[IndexNow]] - [[ikachan]] - [[HTTP Certificate Store Interface]] ]FIG] [58] [[HTTP]] を使って [[Webアプリケーション]]の操作を機械的に指示する手段を提供するものを [[Web API]] などと呼びます。多くの [[Webアプリケーション]]が [[JSON]]、[[XML]]、 [[Atom]]、[CODE(MIME)@en[[[application/x-www-form-urlencoded]]]] などの[[文書形式]]や [[OAuth]]、[[基本認証]]などの[[認証]]方式と [[HTTP]] を組み合わせた [[API]] を提供しています。 * 派生プロトコル [29] 派生, [DFN[HTTPもどき]]といっても色々な度合いがありますが... [41] [[輸送路]]を変えたもの [FIG(short list)[ - [[HTTP over SCTP]] - [[HTTPU]] - [[HTTPMU]] - [[SSDP]] - [[HTTP-DTN]] - [[S-HTTP]] ]FIG] [43] 大きく改変したもの [FIG(short list)[ - [[HTTP-NG]] - [[GridHTTP]] - [[XHTTP]] - [[Reverse HTTP]] - [[Bidirectional HTTP]] ]FIG] [42] [[プロトコル]]の構造を流用したもの [FIG(short list)[ - [[RTSP]] - [[SIP]] - [[MRCP]] - [[SSTP]] - [[Q4S]] - [[ICAP]] - [[ICE]] - [[ICY]] - [[CATP]] ]FIG] [40] [[プロトコル要素]]を流用したもの [FIG(short list)[ - [[WSP]] - [[HTTP over XMPP]] - [[FCAST]] - [[CoAP]] - [[SPDY]] - [[Web Sockets]] - [[HTTP Vocabulary in RDF]] ]FIG] [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]] の開発に大きく関わった人々: [FIG(short list)[ - [[TimBL]] - [[Roy T. Fielding]] - [[mnot]] ]FIG] * 歴史 [6] 初期の [[HTTP]] 仕様案 ([[HTTP92]]) [SRC[>>5]] [REFS[ - [5] ''HTTP: A protocol for networked information'' ]REFS] - 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 (及び隣接する [[URI]], [[HTML]] の一部) についてのチェック集。 快適な [[WWW]] 生活(謎)のために最低限必要なサーバーの配慮をまとめたメモ。 ([[HTML]] [[UA]] でいう [[WAI]] みたいなものかな。) -- いい仕事してますね、 [[W3C]]。 - ''Common User Agent Problems'' -- こっちは [[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] [TIME[1993-11-05]]版: 1994-03-07 18:56, [TIME[2025-05-16T14:58:09.400Z]] - ''IETF - Hypertext Transfer Protocol (HTTP) Working Group'' (ietf-http) - ↑この ietf-http の頁は [[RFC]] になっている [[I-D]] がまだのように載ってたり、古い内容のままですね。 (ietf-http 閉鎖よりまだ前なのかな?) - ''HTTP - Hypertext Transfer Protocol Overview'' [14] [[HTTP]] については中核仕様の他に様々な拡張・派生仕様が策定されました。例えば [[IETF]] [[WebDAV]] [[WG]] ([[ietf-webdav]]) は [[HTTP]] を[[ストレージ]]的に利用可能な [[WebDAV]] 仕様を [[HTTP]] の拡張として定義しました。 - ''IETF WEBDAV Working Group Home Page'' 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] [CITE[IRC logs: freenode / #whatwg / 20091013]] ([TIME[2009-12-09 08:43:01 +09:00]] 版) [20] [CITE[Design Issues for HTTP]] ([TIME[1997-06-06 04:48:52 +09:00]] 版) [21] [CITE[Hypertext Transfer Protocol Version 1.x]] ([TIME[2000-09-27 19:46:32 +09:00]] 版) [22] [CITE@en-US[HTTP - Hypertext Transfer Protocol Overview]] ([TIME[2009-10-26 18:38:01 +09:00]] 版) [23] [CITE[HTTP Problem Statement]] ([TIME[1997-06-06 06:45:05 +09:00]] 版) [24] ( ([TIME[1993-11-05 09:08:00 +09:00]] 版)) [25] ( ([TIME[1993-11-12 08:03:00 +09:00]] 版)) [26] [CITE[Information on http://cantor1.mathematik.uni-halle.de/doc/CERN/doc/draft-ietf-iiir-http-00.txt]] ( ([TIME[2012-07-10 14:37:20 +09:00]] 版)) [27] [CITE@en[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.]] ( ([TIME[2008-12-02 08:52:00 +09:00]] 版)) [28] [CITE[crwlr.net - server header information index | beta]] ( ([TIME[2014-03-05 09:03:07 +09:00]] 版)) [38] [CITE[httpwg/http-extensions]] ( ([TIME[2014-07-30 01:12:42 +09:00]] 版)) [39] [CITE@en[Work in Progress]] ( ([TIME[2014-08-28 07:23:02 +09:00]] 版)) [53] [CITE@en[draft-aboba-rtp-http-02 - Payload Format for HTTP Encoding in RTP]] ( ([TIME[2015-02-02 03:35:25 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [59] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-05 09:33:40 +09:00]] 版) ]FIGCAPTION] > Anything in this specification that refers to HTTP also applies to HTTP-over-TLS, as represented by URLs using the https: scheme. ]FIG] [64] [CITE@en[RFC 3205 - On the use of HTTP as a Substrate for Other Protocols]] ([TIME[2015-06-07 16:22:49 +09:00]] 版) [71] [CITE[Wireless Profiled HTTP Version 29-Mar-2001]] ([TIME[2013-09-23 14:21:12 +09:00]] 版) [72] [CITE[Hypertext Transport Protocol HTTP/1.1]] ( ([TIME[1996-10-21 04:41:52 +09:00]])) [73] [CITE@en[protocol: make normative reference to http (#315)]] ([[andreastt]]著, [TIME[2016-07-19 23:51:12 +09:00]])