HTTP （Hypertext Transfer Protocol 、ハイパーテキスト・トランスファー・プロトコル）は、ハイパーメディア を転送する通信プロトコル であり、主にインターネット 上で利用される。World Wide Web のデータ通信の基盤を支える技術であり、インターネット・プロトコル・スイート の一つである。
TCP やQUIC はアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、1往復のクライアントリクエスト&サーバーレスポンスという形で通信される、と定めたステートレス のプロトコルである[ 1]
HTTPの発明により、インターネット 上でのリソース公開とアクセスが容易になった。クライアントがサーバーとコネクションを確立し1つのHTTPメッセージを書いて送るだけで、サーバー上のリソースがHTTPメッセージとして帰ってくる。ゆえにHTTPで公開されるあらゆるリソースにHTTPという単一の手法でアクセスできるようになった。
HTTPを開発した理由でありかつ現在も広く利用される用途はWorld Wide Web である。Webサーバ とWebブラウザ はHTTPで主に通信しており、ブラウザからのHTTPメッセージに応答してサーバーがHTML テキストやJavaScript コードを送り返し、これをブラウザで表示することでウェブが成立している。
またHTTPはメッセージ形式を定める。基本的な考え方は単純で「何を」「どうして」欲しいのかを伝える。例えばリクエストメッセージ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ページ近くの分量に膨れあがった。
1991年 に最初にドキュメント化されたバージョン[ 2]
GET /index.html 1996年 5月 にRFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。
HTTP/1.0のリクエスト 1997年 1月 にRFC 2068 として初版が発表された。その後、3回改訂され、現在はセマンティクス・キャッシングを除く部分がRFC 9112 で規定されている。
名前ベースバーチャルホスト のため、Hostヘッダーフィールドの規定が追加された。
HTTP/1.1のリクエスト GET /index.html HTTP / 1.1 Host : foo.example.com HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化 、ヘッダ圧縮 、リクエストとレスポンスのパイプライン化 を実現することである。Google によって立ち上げられ[ 3] Chrome だけではなく、他にも、Opera 、Firefox 、Amazon Silk などが対応しているHTTP互換のプロトコルSPDY の人気が高まっていることに対応するために開発された[ 4]
HTTP-over-QUIC（hq）としてIETF が開発していた新たな通信プロトコル が、HTTP/3へと改名される。[ 5] QUIC はトランスポート層 におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。[ 6]
HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと[ 7] ヘッドオブラインブロッキング （英語版 ） [ 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メソッドの一覧 メソッド HTTP/0.9 HTTP/1.0 HTTP/1.1 GET ○ ○ ○ POST ○ ○ PUT △ ○ HEAD ○ ○ DELETE △ ○ OPTIONS ○ TRACE ○ CONNECT ○
GET 指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。 POST 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] 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メッセージと呼ばれる。クライアントからリクエスト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行目以降にヘッダフィールドが続く。さらに空行を挟んで、レスポンスボディとなる。このレスポンスにもトレーラーは無い。
ヘッダの各要素は
フィールド名: 内容 のペアで構成される。
ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURL を表すRefererなどが代表的なフィールドである。
なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。ただし、サーバがバーチャルホスト を利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。
リクエストヘッダ ヘッダ 概要 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: $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ヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。 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が一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。 利用者：AがHTTPの記事を取得。ETagは1234。 利用者：BがHTTPの記事を取得。ETagは1234。 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。 利用者：AがHTTPの記事を編集。ETagは1256になる。 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。 サーバは利用者：Bの書き込みを拒否。 If-Modified-Since 指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。 If-None-Match If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。If-Range クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。 If-Unmodified-Since If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。Last-Modified レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。 Location サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Created のレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。 Max-Forwards プロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。 ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。
いくつかの観点でセキュリティに関する追加機能が存在する。
セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。
HTTPの中で認証を行う仕組みが用意されている。
HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる[ 16] 平文 で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。
HTTPはIETF を始めとした標準化団体により規格化されている。以下はその一部である。
歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン（v1.1, v2, v3）が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている[ 17]
HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。
なお、このようなHTTPの利用に関する文書としてRFC 9205 Building Protocols with HTTP (BCP 56)が存在する。
背景 サブトピック アプリケーション 関連項目 標準
文法とサポート技術 スキーム、オントロジー、ルール セマンティック注釈 共通語彙 マイクロフォーマット語彙
カテゴリ
