以下の内容はhttps://www.weblio.jp/content/HTTPより取得しました。

デジタル大辞泉
索引トップ 用語の索引 ランキング 凡例
デジタル大辞泉デジタル大辞泉

エッチ‐ティー‐ティー‐ピー【HTTP】

読み方：えっちてぃーてぃーぴー

《hypertext transfer protocol》インターネット上でのデータ転送のためのプロトコル。WWWサーバーとブラウザーがHTMLファイルや画像、音声などのデータの送受信に用いられる。ハイパーテキスト転送プロトコル。


DBM用語辞典
索引トップ 用語の索引 ランキング
JERICHO CONSULTINGJERICHO CONSULTING

HTTP

【英】Hypertext Transfer Protocol
別名：ハイパーテキスト・トランスファー・プロトコル

WWWでハイパーテキスト文書にリンクするためのプロトコル。先立つものとして、ウェブサイトのアドレスなど（例えば、http://marketplace.com など）

ネットワーク用語集
索引トップ 用語の索引 ランキング
アライドテレシス株式会社アライドテレシス株式会社

HTTP

Hyper Text Transfer Protocol
WWWサーバーとWWWブラウザ（Webブラウザ）などが、ファイルなどの情報を送受信するのに使うプロトコル。TCP/IPの上位層に位置する。

関連用語：


PHP用語集
索引トップ 用語の索引 ランキング
PHPプロ！PHPプロ！

HTTP

【英】 HyperText Transfer Protocol

WWWブラウザーとWebサーバーの間でHyperText Markup Language (HTML) などのコンテンツをやり取りする際に用いられる通信プロトコル。

関連用語


IT用語辞典バイナリ
索引トップ 用語の索引 ランキング 画像一覧 カテゴリー
IT用語辞典バイナリIT用語辞典バイナリ

HTTP

フルスペル：Hypertext Transfer Protocol
読み方：エイチティーティーピー
別名：ハイパーテキスト転送プロトコル

HTTPとは、ブラウザを使ってウェブ上の情報にアクセスするための方式（通信プロトコル）の名称である。あるいは、「通信プロトコルにはHTTPを使いますよ」と宣言する意味でURLの先頭に掲げられる文字列である。

HTTPは、通信プロトコルの一種である。「プロトコル」とは、日本語では「規約」「典礼」「実施要項」などと訳されるが、つまるところは「正確な意思疎通を図るために構築された約束事」である。たとえば外交の分野では、国旗の掲げ方や、典礼における服装やもてなし方などが、国際的に標準化され共有されている。これによって異国・異文化の賓客にもあらぬ誤解を抱かれずに正しくもてなすことができている。こうした約束事・取り決めが「プロトコル」である。そして、ITの分野においては「サーバー」と「クライアント」が（インターネットを通じて）データを扱う際の通信方式が「プロトコル」と呼ばれる。その中でもWebサーバーとWebブラウザの間のやり取りに用いられるプロトコルが「HTTP」であるというわけである。

ブラウザを使ったアクセスではHTTP（またはHTTPS）が標準的なプロトコルであるが、ブラウザを用いない「ファイル転送」においては「FTP」と呼ばれるプロトコルが多く用いられる。電子メールの送受信に用いられるプロトコルはSMTP、POP、IMAPと複数ある。

HTTPは、ファイル伝送に利用されるFTPや、電子メールのやりとりに用いられるSMTPなどと並び、インターネット上で最も頻繁に利用されるプロトコルの一種となっている。

HTTPは、WWW（World Wide Web）上でサーバー（Webサーバー）とクライアント（Webブラウザ）が、HTML文書などのデータの交換・やり取りを行うための方式として規定されている通信プロトコルである。

HTTPは、TCP上でパケット単位で情報のやりとりを行う。HTTPの大きな特徴として、基本的にステートレスな通信であり、一つの要求（リクエスト）に対して一つの応答（レスポンス）で完結するというシンプルな通信である、という点が挙げられる。リクエストを受けたWebサーバーは、HTMLで記述された文書ファイルやHTMLによって関連付けられたマルチメディアデータなどをクライアントに転送する。Webブラウザは、受信したデータを解析し、レンダリングを行って、整理されたHTML文書として画面に表示する。

HTTPにおけるデータは、制御情報を持つHTTPヘッダ部と、コンテンツデータを含むHTTPボディ部からなる単純な構造をしている。転送可能な情報の種類には、特に制限がない。

なお、「HTTPS」は、HTTPにSSL（Secure Sockets Layer）の暗号化を施し、セキュリティ性を向上させたプロトコルである。つまりHTTPSはHTTPのセキュリティ強化版としての発展型である。HTTPとHTTPSとの違いは「セキュア性」に尽きる。ちなみに、HTTPのポート番号はデフォルトでは80番であり、HTTPSのポート番号はデフォルトで443番となっている。

HTTP1.1において、HTTP要求で指定されるHTTPメソッドには、GET、POST、PUT、HEAD、DELETE、CONNECT、OPTIONS、TRACEなどがある。それぞれの意味は、GETは、相手サーバーからクライアントへのファイル伝送要求、POSTは、クライアントから相手サーバーへのデータ送信要求（HTTPボディ部を用いる）、PUTは、クライアントから相手先サーバーへのファイルのアップロード要求、HEADは、相手先サーバーのファイル更新情報の問い合わせ要求、DELETEは、相手先サーバーのファイルの削除要求、CONNECTは、プロキシの指定要求、OPTIONSは、利用可能なオプションの問い合わせ要求である。

Web上での典型的な利用の仕方としては、おおむね以下の通りである。まず、ユーザーは、Webブラウザ上で参照先ドキュメントのURL（Uniform Resource Locator）を指定する。URLは「http://server.mydomain.jp/dir/document.html」のような形をしている。「http」は、プロトコルの種類（暗号化通信の場合は、httpsとなる）、「server.mydomain.jp」は、接続先ドメイン名を意味する。Webブラウザは、ドメイン名をDNSに問い合わせ、IPアドレスを得て80番ポートに接続する。接続が成功すると、相手先のサーバーに対して、1行目に「GET /dir/document.html HTTP/1.0」のようなデータを持つ、HTTPヘッダ部を持つHTTP要求パケットを送信する。この1行をリクエスト行と呼ぶ。ここで「GET」は、HTTPメソッドの一つで、ファイルの伝送を要求するものである。次の「/dir/document.html」は伝送要求する文書名で、サーバー上の論理的なパス名で指定する（物理的なパス名と一致するとは限らない）。最後の「HTTP/1.0」は利用するHTTPプロトコルのバージョンを指定している。この要求を受信した相手先のWebサーバーは、「HTTP/1.0 200 OK」のような行（レスポンス行）を含むHTTPレスポンスを返す。ここで、「HTTP/1.0」は、HTTPプロトコルのバージョン、「200」はステータス番号で200は正常の意味である。異常の場合は200番以外の数値が返る。「OK」は、補足メッセージで、エラー時には付加的な情報を返す。要求された文書データは、HTTPレスポンスのHTTPボディ部で伝送される。ヘッダ部とボディ部の区切りは、空行1行で指定される。

WebページにアクセスするにはURL（いわゆるアドレス）が必要であり、URLの先頭には一律「http(s)」をつける必要がある。WebブラウザによってはURL表示欄（アドレスバー）上に特に「http(s)」が表示されない場合も多いが、これは単に表示が省略されているだけである。

通信方式のほかの用語一覧
TCP/IP：  finger  FTP  FYI  HTTP  HTTPS  パッシブモード  ホストアドレス
>>TCP/IPカテゴリの他の用語

PHP関数リファレンス
索引トップ 用語の索引 ランキング
PHP Documentation GroupPHP Documentation Group

HTTP

この HTTP 拡張モジュールの狙いは、PHP アプリケーションのために便利で強力な機能を提供することです。
HTTP の URL、日付、リダイレクト、ヘッダおよびメッセージを 使いやすくし、クライアントの希望する言語および文字セットの ネゴシエーション手段を提供します。 また、任意のデータを送信する際にキャッシュやリジュームの機能を もたせることができます。
CURL サポート込みでビルドされている場合は、 強力なリクエスト機能を提供します。PHP 5 以降では、 複数のリクエストを平行して実行することができます。
このマニュアルでは、API リファレンスに加えて インストールや設定の方法、定義済みのグローバル定数などを 以下の節で説明しています。
インストール
設定
グローバル定数

目次

インストール — HTTP 拡張モジュールのインストールおよび設定
設定 — http モジュールの設定ディレクティブ
定数 — 定義済みの http モジュールの定数
HttpMessage — HTTP メッセージクラス
HttpMessage::__construct — HttpMessage のコンストラクタ
HttpMessage::fromString — 文字列から HttpMessage を作成する
HttpMessage::toString — 文字列表現を取得する
HttpMessage::toMessageTypeObject — メッセージの型に応じた HTTP オブジェクトを作成する
HttpMessage::guessContentType — content type を推測する
HttpMessage::detach — HttpMessage をデタッチする
HttpMessage::prepend — メッセージを先頭に追加する
HttpMessage::reverse — メッセージチェインを逆順にする
HttpMessage::send — メッセージを送信する
HttpMessage::getParentMessage — 親メッセージを取得する
HttpMessage::getType — メッセージの型を取得する
HttpMessage::setType — メッセージの型を設定する
HttpMessage::getHttpVersion — HTTP バージョンを取得する
HttpMessage::setHttpVersion — HTTP バージョンを設定する
HttpMessage::getHeaders — メッセージのヘッダを取得する
HttpMessage::getHeader — ヘッダを取得する
HttpMessage::addHeaders — ヘッダを追加する
HttpMessage::setHeaders — ヘッダを設定する
HttpMessage::getBody — メッセージの本文を取得する
HttpMessage::setBody — メッセージの本文を設定する
HttpMessage::getRequestMethod — リクエストメソッドを取得する
HttpMessage::setRequestMethod — リクエストメソッドを設定する
HttpMessage::getRequestUrl — リクエスト URL を取得する
HttpMessage::setRequestUrl — リクエスト URL を設定する
HttpMessage::getResponseCode — レスポンスコードを取得する
HttpMessage::setResponseCode — レスポンスコードを設定する
HttpMessage::getResponseStatus — レスポンスのステータスを取得する
HttpMessage::setResponseStatus — レスポンスのステータスを設定する
HttpQueryString — HTTP クエリ文字列クラス
HttpQueryString::__construct — HttpQueryString のコンストラクタ
HttpQueryString::singleton — HttpQueryString のシングルトン
HttpQueryString::get — クエリ文字列 (の一部) を取得する
HttpQueryString::mod — クエリ文字列の複製を変更する
HttpQueryString::set — クエリ文字列パラメータを設定する
HttpQueryString::toArray — クエリ文字列を配列で取得する
HttpQueryString::toString — クエリ文字列を取得する
HttpQueryString::xlate — クエリ文字列の文字セットを変更する
HttpDeflateStream — HTTP 圧縮ストリームクラス
HttpDeflateStream::__construct — HttpDeflateStream クラスのコンストラクタ
HttpDeflateStream::update — 圧縮ストリームを更新する
HttpDeflateStream::flush — 圧縮ストリームをフラッシュする
HttpDeflateStream::finish — 圧縮ストリームを終了する
HttpInflateStream — HTTP 展開ストリーム
HttpInflateStream::__construct — HttpInflateStream クラスのコンストラクタ
HttpInflateStream::update — 展開ストリームを更新する
HttpInflateStream::flush — 展開ストリームをフラッシュする
HttpInflateStream::finish — 展開ストリームを終了する
HttpRequest — HTTP リクエストクラス
HttpRequest::addCookies — クッキーを追加する
HttpRequest::addHeaders — ヘッダを追加する
HttpRequest::addPostFields — POST フィールドを追加する
HttpRequest::addPostFile — POST ファイルを追加する
HttpRequest::addPutData — PUT データを追加する
HttpRequest::addQueryData — クエリデータを追加する
HttpRequest::addRawPostData — 生の POST データを追加する
HttpRequest::addSslOptions — SSL オプションを追加する
HttpRequest::clearHistory — 履歴を消去する
HttpRequest::__construct — HttpRequest のコンストラクタ
HttpRequest::enableCookies — クッキーを有効にする
HttpRequest::getContentType — content type を取得する
HttpRequest::getCookies — クッキーを取得する
HttpRequest::getHeaders — ヘッダを取得する
HttpRequest::getHistory — 履歴を取得する
HttpRequest::getMethod — メソッドを取得する
HttpRequest::getOptions — オプションを取得する
HttpRequest::getPostFields — POST フィールドを取得する
HttpRequest::getPostFiles — POST ファイルを取得する
HttpRequest::getPutData — PUT データを取得する
HttpRequest::getPutFile — PUT ファイルを取得する
HttpRequest::getQueryData — クエリデータを取得する
HttpRequest::getRawPostData — 生の POST データを取得する
HttpRequest::getRawRequestMessage — 名前のリクエストメッセージを取得する
HttpRequest::getRawResponseMessage — 生のレスポンスメッセージを取得する
HttpRequest::getRequestMessage — リクエストメッセージを取得する
HttpRequest::getResponseBody — レスポンスの本文を取得する
HttpRequest::getResponseCode — レスポンスコードを取得する
HttpRequest::getResponseCookies — レスポンスのクッキーを取得する
HttpRequest::getResponseData — レスポンスデータを取得する
HttpRequest::getResponseHeader — レスポンスヘッダを取得する
HttpRequest::getResponseInfo — レスポンスの情報を取得する
HttpRequest::getResponseMessage — レスポンスメッセージを取得する
HttpRequest::getResponseStatus — レスポンスのステータスを取得する
HttpRequest::getSslOptions — ssl オプションを取得する
HttpRequest::getUrl — url を取得する
HttpRequest::resetCookies — クッキーをリセットする
HttpRequest::send — リクエストを送信する
HttpRequest::setContentType — content type を設定する
HttpRequest::setCookies — クッキーを設定する
HttpRequest::setHeaders — ヘッダを設定する
HttpRequest::setMethod — メソッドを設定する
HttpRequest::setOptions — オプションを設定する
HttpRequest::setPostFields — POST フィールドを設定する
HttpRequest::setPostFiles — POST ファイルを設定する
HttpRequest::setPutData — PUT データを設定する
HttpRequest::setPutFile — PUT ファイルを設定する
HttpRequest::setQueryData — クエリデータを設定する
HttpRequest::setRawPostData — 生の POST データを設定する
HttpRequest::setSslOptions — SSL オプションを設定する
HttpRequest::setUrl — URL を設定する
HttpRequestPool — HTTP リクエストプールクラス
HttpRequestPool::attach — HttpRequest をアタッチする
HttpRequestPool::__construct — HttpRequestPool のコンストラクタ
HttpRequestPool::__destruct — HttpRequestPool のデストラクタ
HttpRequestPool::detach — HttpRequest をデタッチする
HttpRequestPool::getAttachedRequests — アタッチされているリクエストを取得する
HttpRequestPool::getFinishedRequests — 終了したリクエストを取得する
HttpRequestPool::reset — リクエストプールをリセットする
HttpRequestPool::send — すべてのリクエストを送信する
HttpRequestPool::socketPerform — ソケットアクションを実行する
HttpRequestPool::socketSelect — ソケットの選択を実行する
HttpResponse — HTTP レスポンスクラス
HttpResponse::capture — スクリプトの出力を取り込む
HttpResponse::getBufferSize — バッファサイズを取得する
HttpResponse::getCacheControl — cache control を取得する
HttpResponse::getCache — キャッシュを取得する
HttpResponse::getContentDisposition — content disposition を取得する
HttpResponse::getContentType — content type を取得する
HttpResponse::getData — データを取得する
HttpResponse::getETag — ETag を取得する
HttpResponse::getFile — ファイルを取得する
HttpResponse::getGzip — gzip を取得する
HttpResponse::getHeader — ヘッダを取得する
HttpResponse::getLastModified — 最終更新日時を取得する
HttpResponse::getStream — ストリームを取得する
HttpResponse::getThrottleDelay — throttle delay を取得する
HttpResponse::guessContentType — content type を推測する
HttpResponse::send — レスポンスを送信する
HttpResponse::setBufferSize — バッファサイズを設定する
HttpResponse::setCacheControl — cache control を設定する
HttpResponse::setCache — キャッシュを設定する
HttpResponse::setContentDisposition — content disposition を設定する
HttpResponse::setContentType — content type を設定する
HttpResponse::setData — データを設定する
HttpResponse::setETag — ETag を設定する
HttpResponse::setFile — ファイルを設定する
HttpResponse::setGzip — gzip を設定する
HttpResponse::setHeader — ヘッダを設定する
HttpResponse::setLastModified — 最終更新日時を設定する
HttpResponse::setStream — ストリームを設定する
HttpResponse::setThrottleDelay — throttle delay を設定する
http_cache_etag — ETag でキャッシュする
http_cache_last_modified — 最終更新日時でキャッシュする
http_chunked_decode — chunked-encoded データをデコードする
http_deflate — データを圧縮する
http_inflate — データを展開する
http_get_request_body_stream — リクエストの本文をストリームとして取得する
http_get_request_body — リクエストの本文を文字列として取得する
http_get_request_headers — リクエストヘッダを配列として取得する
http_date — HTTP の RFC に準拠した日付を作成する
http_support — 組み込みの HTTP サポートを調べる
http_match_etag — ETag を比較する
http_match_modified — 最終更新日時を比較する
http_match_request_header — 任意のヘッダを比較する
http_build_cookie — クッキー文字列を作成する
http_negotiate_charset — クライアントが希望している文字セットを選択する
http_negotiate_ctype — クライアントが希望している content type を選択する
http_negotiate_language — クライアントが希望している言語を選択する
ob_deflatehandler — 圧縮出力ハンドラ
ob_etaghandler — ETag 出力ハンドラ
ob_inflatehandler — 展開出力ハンドラ
http_parse_cookie — HTTP クッキーをパースする
http_parse_headers — HTTP ヘッダをパースする
http_parse_message — HTTP メッセージをパースする
http_parse_params — パラメータリストをパースする
http_get — GET リクエストを実行する
http_head — HEAD リクエストを実行する
http_post_data — エンコードされたデータを使用して POST リクエストを実行する
http_post_fields — エンコードされる前のデータを使用して POST リクエストを実行する
http_put_data — データを使用して PUT リクエストを実行する
http_put_file — ファイルを使用して PUT リクエストを実行する
http_put_stream — ストリームを使用して PUT リクエストを実行する
http_request_method_exists — リクエストメソッドが存在するかどうかを調べる
http_request_method_name — リクエストメソッド名を取得する
http_request_method_register — リクエストメソッドを登録する
http_request_method_unregister — リクエストメソッドの登録を解除する
http_request — 独自のリクエストを実行する
http_request_body_encode — リクエスト本文をエンコードする
http_redirect — HTTP リダイレクトを発行する
http_send_content_disposition — Content-Disposition を送信する
http_send_content_type — Content-Type を送信する
http_send_data — 任意のデータを送信する
http_send_file — ファイルを送信する
http_send_last_modified — Last-Modified を送信する
http_send_status — ステータスを送信する
http_send_stream — ストリームを送信する
http_throttle — HTTP 抑止処理
http_build_str — クエリ文字列を組み立てる
http_build_url — URL を組み立てる

ウィキペディア
索引トップ ランキング カテゴリー
ウィキペディアウィキペディア

HTTP

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/02/25 07:50 UTC 版)

HTTP
通信プロトコル
目的 ハイパーテキストなどの転送
開発者
導入 1991年 (35年前) (1991)
派生先 HTTP/2、HTTP/3、WebDAV
OSI階層 アプリケーション層
ポート 80
RFC
HTTP
主要項目
リクエストメソッド
ヘッダーフィールド（英語版）
ステータスコード
認証方式
セキュリティホール
TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

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ページ近くの分量に膨れあがった。

HTTP/0.9

1991年に最初にドキュメント化されたバージョン[2]。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。 

GET /index.html

HTTP/1.0

1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。

HTTP/1.0のリクエスト 
GET /index.html HTTP/1.0

HTTP/1.1

1997年1月に RFC 2068 として初版が発表された。その後、3回改訂され、現在はセマンティクス・キャッシングを除く部分が RFC 9112で規定されている。

名前ベースバーチャルホストのため、Hostヘッダーフィールドの規定が追加された。

HTTP/1.1のリクエスト 
GET /index.html HTTP/1.1
Host: foo.example.com

HTTP/2

→詳細は「HTTP/2」を参照

HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ[3]、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された[4]。

HTTP/3

→詳細は「HTTP/3」を参照

HTTP-over-QUIC（hq）としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。[5] IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。[6]

HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと[7]、ヘッドオブラインブロッキング（英語版）を回避するためのヘッダ圧縮の変更（HTTP/3用にQPACKが開発されている）[8]などの差異がある。

→Googleが試験的に開発していたプロトコルについては「QUIC」を参照

動作

通信の開始

他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。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の持続的接続」を参照

パイプライン

クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。

→詳細は「HTTPパイプライン」を参照

リクエストメソッド

HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドが大部分を占める。

→「en:Request method」も参照
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
→「POST (HTTP)」も参照
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]で管理されている。WebDavで使用するものや、 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疑似ヘッダーフィールドでホスト名を指定する。

リダイレクト

→「リダイレクト (HTTP) § HTTPリダイレクト」も参照

別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。

クッキー

→詳細は「HTTP cookie」を参照

HTTPメッセージ

リクエストとレスポンスでやり取りされるデータは、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行目以降にヘッダフィールドが続く。 さらに空行を挟んで、レスポンスボディとなる。 このレスポンスにもトレーラーは無い。

HTTPヘッダフィールド

ヘッダの各要素は

フィールド名: 内容

のペアで構成される。

ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。

なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。 ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。

HTTPヘッダフィールドの一覧

リクエストヘッダ
ヘッダ 概要 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」を参照
クライアントが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が一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。
→「if文」も参照
  1. 利用者：AがHTTPの記事を取得。ETagは1234。
  2. 利用者：BがHTTPの記事を取得。ETagは1234。
  3. 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
  4. 利用者：AがHTTPの記事を編集。ETagは1256になる。
  5. 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
  6. サーバは利用者：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メソッドと共に用いられる。

HTTPステータスコード

ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。

→詳細は「HTTPステータスコード」を参照

セキュリティ技術

いくつかの観点でセキュリティに関する追加機能が存在する。

HTTPS

→詳細は「HTTPS」を参照

セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。

HTTP認証

→詳細は「HTTP認証」を参照

HTTPの中で認証を行う仕組みが用意されている。

Basic認証

HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる[16]。平文で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。

→詳細は「Basic認証」を参照

Digest認証

→詳細は「Digest認証」を参照

規格

HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。

セマンティクス キャッシュ 手続き
HTTP/1.1 RFC 9110 RFC 9111 RFC 9112
HTTP/2 RFC 9113
HTTP/3 RFC 9114

歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン（v1.1, v2, v3）が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている[17]。

派生・拡張プロトコル

HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。

なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。

脚注

[脚注の使い方]
  1. ^ "The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols ... HTTP is a stateless request/response protocol for exchanging 'messages' across a connection." RFC 9110.
  2. ^ The HTTP Protocol As Implemented In W3
  3. ^ Sebastian Anthony (2012年3月28日). “S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0”. ExtremeTech. 2014年9月23日閲覧。
  4. ^ Jerome Louvel (2011年10月6日). “Can the rise of SPDY threaten HTTP?”. Restlet. 2012年1月21日時点のオリジナルよりアーカイブ。2014年9月23日閲覧。
  5. ^ “Gigazine『UDPベースの「HTTP-over-QUIC」が新HTTPバージョン「HTTP/3」に名称変更される』”. GIGAZINE (2018年11月14日). 2018年11月14日閲覧。
  6. ^ IETF Meetingの資料スライド
  7. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “後述のストリームの管理がQUICレイヤに移り、それにあわせフレームの変更やQUICストリームの利用方法の定義”
  8. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “ヘッドオブラインブロッキング避けるために、HPACKをQUIC用に改良したQPACKを用いる”
  9. ^ “RFC 2817 Upgrading to TLS Within HTTP/1.1” (2000年5月). 2019年4月26日閲覧。 “The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy servers", by Ari Luotonen of Netscape Communications Corporation.”
  10. ^ “RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing” (2014年6月). 2019年4月26日閲覧。 “This specification also updates the use of CONNECT to establish a tunnel, previously defined in RFC 2817, and defines the "https" URI scheme that was described informally in RFC 2818.”
  11. ^ Hypertext Transfer Protocol (HTTP) Method Registry
  12. ^ RFC 9110, 6. Message Abstraction
  13. ^ HTTP Content Coding Registry
  14. ^ “RFC 1864 The Content-MD5 Header Field” (英語). Internet Engineering Task Force (1995年10月). 2021年1月30日閲覧。 “This document specifies a data integrity service that protects data from accidental modification while in transit from the sender to the recipient.”
  15. ^ “RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content” (英語). Internet Engineering Task Force (2014年6月). 2021年1月30日閲覧。 “The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.”
  16. ^ 『HTTPプロトコル―セキュア&スケーラブルなWeb開発』 Stephen Thomas 著、葛西 重夫 訳、ソフトバンクパブリッシング[要ページ番号]
  17. ^ “JPNIC News & Views vol.1647【臨時号】第103回IETF報告 [第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3への改称～”. 日本ネットワークインフォメーションセンター (2018年12月13日). 2021年6月28日閲覧。

関連項目

ウィクショナリーにHTTPの項目があります。

外部リンク
背景
サブトピック
アプリケーション
  • Semantic analytics
  • Semantic broker
  • Semantic computing
  • Semantic mapper
  • Semantic matching
  • Semantic publishing
  • Semantic reasoner
  • Semantic search
  • Semantic service-oriented architecture
  • Semantic wiki
関連項目
標準
文法とサポート技術
スキーム、オントロジー、ルール
  • Common Logic
  • OWL
  • RDFS
  • Rule Interchange Format
  • Semantic Web Rule Language
  • ALPS
セマンティック注釈
共通語彙
マイクロフォーマット語彙
カテゴリ
公式
非公式
プロトコル一覧（英語版）
サーバサイド
通信プロトコル
API
トピックス
クライアントサイド
Browser APIs
Web API
W3C
クロノス
その他
トピックス
関連項目

MILLENNIUM PARADE

(HTTP から転送)

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/03/01 05:39 UTC 版)

この項目では、音楽プロジェクトについて説明しています。同名のアルバムについては「THE MILLENNIUM PARADE」をご覧ください。
常田大希 > MILLENNIUM PARADE
MILLENNIUM PARADE
別名
  • millennium parade（旧称）
    ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄ[1]
出身地 日本
ジャンル
活動期間 2019年 -
レーベル
公式サイト MILLENNIUM PARADE Official website
メンバー
MILLENNIUM PARADE
YouTube
チャンネル
活動期間 2020年 -
ジャンル 音楽
登録者数 44.2万人
総再生回数 1億6780万回
チャンネル登録者数・総再生回数は
2024年10月29日時点。
テンプレートを表示

MILLENNIUM PARADE（ミレニアムパレード）は、King Gnuのメンバーでもある常田大希が主宰する音楽プロジェクト。愛称は「ミレパ」。常田自身のソロプロジェクトDaiki Tsuneta Millennium Parade（DTMP）を前身とし、2019年に結成された[2]。

概要

“世界から見た東京の音”をテーマとし、自身のクリエイティブチームPERIMETRONと共に、様々なアーティストやクリエイターを巻き込み発信する音楽プロジェクトである。

2019年よりmillennium paradeとして活動を開始。

2021年には自身初となるアルバム、THE MILLENNIUM PARADEをリリース。完全生産限定盤では、12inchのスペシャルBOXに、初回限定盤（CD +Blu-ray）、オリジナル小鬼フィギュア3体、また『構想盤』としてDTMP時代にリリースされた楽曲を収録したカセットテープが収められていて、millennium paradeの世界観を敷き詰めた内容になっている[3]。

2024年、EPIC USおよびRCA UKの2社との契約を発表すると同時に、全大文字表記の「MILLENNIUM PARADE」へと改名した[4]。この改名に先がけ、各種配信サービス等にてmillennium parade名義で配信されていた楽曲のアーティスト名が彝文字を使用した「ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄ」に変更された[1]。同時に、同名義の楽曲のジャケットアートワークやミュージックビデオのサムネイルなども古びた見た目のものに差し替えられた[1]。

メンバー

曲によってボーカルやプレイヤーは変動するが、主なメンバーは以下の通り[5]。

その他のメンバー

主にmillennium parade時代にグループの中心となって活動していたメンバーは以下の通り。

ディスコグラフィ

millennium paradeのディスコグラフィ
リリースリスト
↙スタジオ・アルバム 2
↙シングル 7
↙先行配信 8
↙楽曲提供・参加作品 3

シングル

  発売日 タイトル ボーカル 規格 収録アルバム 備考
millennium parade
1st 2019年5月22日 Veil ermhoi デジタル・ダウンロード -
2nd 2019年6月28日 Plankton THE MILLENNIUM PARADE
3rd 2019年9月27日 Stay!!! Chara -
4th 2019年12月6日 lost and found ermhoi THE MILLENNIUM PARADE
5th 2020年4月22日 Fly with me ermhoi、HIMI、森洸大、長塚健斗 CD、アナログ盤、デジタル・ダウンロード [注 1]
6th 2020年10月2日 Philip 中野裕太、常田大希 デジタル・ダウンロード
7th 2021年8月18日 U Belle(中村佳穂) CD、デジタル・ダウンロード
8th 2022年6月1日 Secret Ceremony/No Time to Cast Anchor ermhoi、timetheft [注 2]
9th 2023年5月17日 W●RK/2◯45 椎名林檎、常田大希 CD、デジタル・ダウンロード [6]
MILLENNIUM PARADE
1st 2024年5月10日 GOLDENWEEK Believve デジタル・ダウンロード
2nd 2024年7月26日 M4D LUV Believve
3rd 2024年10月18日 KIZAO Rauw Alejandro、Tainy、常田大希

先行配信

  発売日 タイトル ボーカル 収録アルバム オリコン最高位（DS[7]）
1st 2021年1月8日 2992 ermhoi THE MILLENNIUM PARADE 42位
2nd 2021年1月22日 FAMILIA 井口理、常田大希 40位
3rd 2021年2月5日 Bon Dance ermhoi -
4th 2021年7月12日 U Belle(中村佳穂) 1位
5th 2022年5月20日 Secret Ceremony timetheft、ermhoi 33位
6th 2022年5月27日 No Time to Cast Anchor ermhoi 41位
7th 2023年4月1日 W●RK 椎名林檎、常田大希 4位

アルバム

  発売日 タイトル 販売形態 規格品番 収録曲
Daiki Tsuneta Millennium Parade 名義（APOLLO SOUNDSレーベル）
1st 2016年7月20日 http:// CD APLS-1608
全20曲
  1. Angya
  2. Ennui
  3. Mannequin
  4. WWW
  5. θ
  6. Onibi
  7. Heroine
  8. Kowloon
  9. com
  10. Down&Down
  11. #blank
  12. Mirror Neuron
  13. Ice will not burn.
  14. Sweet Complex
  15. Internet meme
  16. Dr.Brodsky
  17. Ludovico Technique
  18. Prêt
  19. Porter
  20. Kink
millennium parade 名義（Ariolaレーベル）
1st 2021年2月10日 THE MILLENNIUM PARADE CD BVCL-1136
→詳細は「THE MILLENNIUM PARADE § 収録曲」を参照
CD+Blu-ray BVCL-1134/5
（初回生産限定盤）
CD+Blu-ray+カセット+グッズ BVCL-1130/3
（完全生産限定盤）
2021年8月21日 アナログ盤（12inch2枚組） BVJL-51/2
（完全生産限定盤）

楽曲提供・参加作品

楽曲提供

参加作品

発売日 収録曲 収録作品名 アーティスト 販売形態 備考
Daiki Tsuneta Millennium Parade 名義
2017年9月6日 Interlude #1(feat. Daiki Tsuneta Millennium Parade) Castor WONK CD・配信
2017年11月22日 bit MONK’ｓ Playhouse Daiki Tsuneta Millennium Parade
2018年3月28日 革命前夜 Remix by Daiki Tsuneta Millennium Parade from JAPAN２ Tempalay LP+7インチシングル アナログ盤のみ収録。
millennium parade / ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄ名義
2020年6月24日 Fly with me THEME SONGS+O.S.T. GHOST IN THE SHELL:SAC_2045 millennium parade × ghost in the shell: SAC_2045 アナログ盤
Fly with me(opening ver.)
2021年7月30日 U 竜とそばかすの姫 オリジナル・サウンドトラック millennium parade × Belle 配信 配信版のみ収録。
2022年2月9日(日本国内) U（English Version） "BELLE" Original Motion Picture Soundtrack Uの英語版。
歌唱はカイリー・マクニール（英語版） が担当[10]。
2022年9月23日(日本国内) U（Chinese Version） "BELLE" Original Motion Picture Soundtrack [Chinese Edition] Uの中国語版。
歌唱はNeekoが担当。
U（German Version） "BELLE" Original Motion Picture Soundtrack [German Edition] Uのドイツ語版。
歌唱はララ・トラウトマン（ドイツ語版） が担当。
U（Norwegian Version） "BELLE" Original Motion Picture Soundtrack [Norwegian Edition] Uのノルウェー語版。
歌唱は ハンナ・ストームが担当。
2026年3月11日 W●RK
2○45 		禁じ手 ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄと椎名林檎 CD・配信

タイアップ

起用年 曲名 タイアップ
2019年 lost and found 『Dior and RIMOWA』コラボレーションムービー[11]
2020年 Fly with me Netflix独占配信アニメーション『攻殻機動隊 SAC 2045』オープニングテーマ[12]
Philip 『adidas CASUAL Collection』ウェブCMソング[13]
2021年 2992 NHKスペシャルシリーズ『2030 未来への分岐点』テーマ音楽[14]
FAMILIA 映画『ヤクザと家族 The Family』主題歌[15]
Trepanation 映画『ホムンクルス』メインテーマ[16]
U 映画『竜とそばかすの姫』メインテーマ[17]
Fly with me 映画『攻殻機動隊 SAC_2045 持続可能戦争』主題歌[18]
Bon Dance 『第34回東京国際映画祭』フェスティバルソング[19]
2022年 Secret Ceremony Netflix独占配信アニメーション『攻殻機動隊 SAC_2045 SEASON2』オープニングテーマ[20]
No Time to Cast Anchor Netflix独占配信アニメーション『攻殻機動隊 SAC_2045 SEASON2』エンディングテーマ[20]
Mannequin[注 3] 展覧会「アンディー・ウォーホル・キョウト/ANDY WARHOL KYOTO」テーマソング[21]
2023年 W●RK テレビ東京系アニメ『地獄楽』オープニングテーマ[22]
Secret Ceremony 映画『攻殻機動隊 SAC_2045 最後の人間』主題歌[23]
No Time to Cast Anchor
2024年 GOLDENWEEK PlayStation 『PLUSE Elite ワイヤレスヘッドセッド』北米タイアップソング[24]

受賞歴

年 賞 受賞
2020年 MTV VMAJ 2020 最優秀オルタナティブビデオ賞／Best Alternative Video「Fly with me」[25]
2021年 MTV VMAJ 2021 最優秀コラボレーションビデオ賞／Best Collaboration Video「U」[26]
2022年 SPACE SHOWER MUSIC AWARDS 2022 BEST GROUP ARTIST[27]
BEST MOVIE SONG「U」[27]
BEST CG/ANIMATION VIDEO「Bon Dance」[27]
第14回CDショップ大賞 2022 入賞『THE MILLENNIUM PARADE』[28]
コメント大賞『THE MILLENNIUM PARADE』[28]
2023年 MTV VMAJ 2023 最優秀コラボレーションビデオ賞／Best Collaboration Video「W●RK」[29]
2025年 第12回 新千歳空港国際アニメーション映画祭 短編部門 ミュージックアニメーションコンペティション入賞「M4D LUV」[30]

ライブ

ワンマンライブ

公演年 公演名 公演日 会場
2019 “millennium parade Launch Party” 2019年5月22日(水) 恵比寿LIQUIDROOM
millennium parade live 2019 2019年12月3日(火) なんばHatch
2019年12月5日(木) 新木場STUDIO COAST
2020 millennium parade 3D LIVE 2020 2020年12月23日(水) 東京国際フォーラム・ホールA
2021 millennium parade Live 2021
"THE MILLENNIUM PARADE" 		2021年10月2日(土) 東京ガーデンシアター
2021年10月3日(日)
2021年10月4日(月)
2021年10月6日(水) 大阪フェスティバルホール
2021年10月7日(木)
2024 "WHO AND HOW TOUR 2024"※全公演中止[31] 2024年11月2日 (土) Lunario del Auditorio Nacional（メキシコ）
2024年11月4日 (月) The Fonda Theater（アメリカ）
2024年11月7日 (木) Irving Plaza（アメリカ）
2024年11月9日 (土) Danforth Music Hall（カナダ）
2024年11月14日 (木) Festsaal Kreuzberg（ドイツ）
2024年11月16日 (土) Le Trianon（フランス）
2024年11月18日 (月) HERE at Outernet（イギリス）
2024年11月20日 (水) TivoliVredenburg Ronda（オランダ）
2024年12月19日 (木) 東京ガーデンシアター（日本）
2024年12月20日 (金)

フェス

展覧会

『#014 ヌーミレパーク（仮）』DIRECTED BY PERIMETRON
常田大希が率いるKing Gnuとmillennium paradeの世界観をPERIMETRONとともに再現した、Ginza Sony Park（東京都銀座）にて開催されたプログラム。ミュージックビデオで実際に使用された小道具の展示、ミュージックビデオに登場した3DCG映像の再現、ライブで使用された3D映像の投影など、様々な細部まで拘った作品が展示された[35][36]。
Sony Park展 「④映画は、森だ。」 with millennium parade
2021年6月26日-9月30日にGinza Sony Park（東京都銀座）にて開催されたプログラム「Sony Park展」の展示の一つ。Sony Park展では、岡崎体育、奥田民生、東京スカパラダイスオーケストラ、millennium parade、YOASOBI、Creepy Nutsの6組のアーティストが体験型企画を展開。ゲーム、音楽、映画、エレクトロニクス、半導体、金融の6つのテーマのうち、millennium paradeは映画を担当し、8月16日-27日に展示を行った。PERIMETRONとともに期間限定ミニシアターの「THE MILLENNIUM PARADE THEATER」を展示し、Bon DanceのMVとスペシャル映像が上映された[35]。
また、同内容のプログラム「Sony Park展 KYOTO」は2022年11月11日-23日に京都新聞印刷工場跡にて開催された[37]。
MANGA in New York presented by Ginza Sony Park Project
2023年10月27日-11月5日にGinza Sony Park Projectがニューヨークにて開催したプログラム。一乗ひかる、寺田克也、たかくらかずき、平岡政展、ますだみく、millennium paradeの6組のアーティストが6つのテーマ「Pioneer」「Dreams」「Diversity」「Creativity」「Curiosity」「Sincerity」に合わせ、６つのオリジナルストーリーのマンガを制作[38]。millennium paradeの制作した『DREAM PILL - ドリーム・ピル』は、2045年の東京をイメージした仮想世界「混沌東京」で享楽的な生活を送る少年Ａがドリームピル（夢見る薬）を手にして新たな没入体験を得る内容となっている[39]。

出演

NHK紅白歌合戦出場歴

番組名 日付 曲目 備考
第72回NHK紅白歌合戦 2021年12月31日 U millennium parade × Belle（中村佳穂）として初出場。

テレビ

脚注

[脚注の使い方]

脚注

  1. ^ CD版と配信版の「millennium parade × ghost in the shell:SAC_2045 version」はフライングドッグから、アナログ盤と配信版の「millennium parade version」はアリオラジャパンからリリース。
  2. ^ CDは全形態フライングドッグ、配信はアリオラジャパンからリリース。
  3. ^ Daiki Tsuneta Millennium Parade名義の楽曲。

出典

  1. ^ a b c “常田大希のヴィジョンを考察　MILLENNIUM PARADE改名の背景、新章の狙い”. Rolling Stone Japan(ローリングストーン ジャパン）. CCCミュージックラボ. 2024年5月6日閲覧。
  2. ^ “King Gnu常田大希、新プロジェクト・millennium paradeで世界へ”. CINRA.NET (2019年5月31日). 2021年3月30日閲覧。
  3. ^ “millennium paradeが初アルバムリリース、12月には国際フォーラムで有観客ライブ”. 音楽ナタリー. ナターシャ. 2024年5月6日閲覧。
  4. ^ Inc, Natasha. “常田大希率いるMILLENNIUM PARADEが欧米レーベル2社と契約、世界進出を本格化”. 音楽ナタリー. 2024年5月4日閲覧。
  5. ^ “millennium paradeの2021年2月1日の投稿”. www.instagram.com. 2021年2月6日閲覧。
  6. ^ Inc, Natasha. “millennium parade × 椎名林檎「地獄楽」主題歌の配信決定、CDシングルには別のコラボ曲収録”. 音楽ナタリー. 2023年3月19日閲覧。
  7. ^ “millennium paradeのデジタルシングル売上TOP7作品”. ORICON NEWS. 2024年7月18日閲覧。
  8. ^ “WONK所属レーベル〈epistroph〉がアパレル・ラインを立ち上げ。ローンチ・イベントも開催”. Spincoaster (2017年1月13日). 2021年3月30日閲覧。
  9. ^ “new balance × CHARI&CO × BEAMS T in NEW YORK CITY”. BEAMS. 2021年3月30日閲覧。
  10. ^ mllnnmprdのツイート、2022年3月12日閲覧。
  11. ^ “常田大希 millennium parade、”東京の街”をテーマに、DIORとのコラボレーションが実現「今までで一番いい曲が書けた」”. DE COLUM (2019年11月18日). 2021年3月30日閲覧。
  12. ^ “常田大希が描き出す純度の高い“驚き” millennium parade「Fly with me」から感じた比類なき創造性を考察”. Real Sound (2020年5月1日). 2021年3月30日閲覧。
  13. ^ “常田大希、millennium paradeの新曲を起用したadidas×アルペン共同キャンペーンのWEB CMに登場”. M-ON! MUSIC (2020年9月18日). 2021年3月30日閲覧。
  14. ^ “常田大希率いるmillennium parade、NHKスペシャルシリーズテーマ曲「2992」先行配信　地上波初パフォーマンスも”. Real Sound (2021年1月7日). 2021年3月30日閲覧。
  15. ^ “millennium paradeが綾野剛主演のヤクザ映画に主題歌提供、ボーカルは井口理”. 音楽ナタリー (ナターシャ). (2020年10月26日). https://natalie.mu/music/news/402134 2020年10月26日閲覧。 
  16. ^ “millennium parade、映画「ホムンクルス」で綾野剛主演作と2回目のタッグ”. 音楽ナタリー (ナターシャ). (2021年2月17日). https://natalie.mu/music/news/416692 2021年2月17日閲覧。 
  17. ^ “「竜とそばかすの姫」メインテーマはmillennium parade×中村佳穂、常田大希「最高に刺激的な製作」”. 音楽ナタリー (ナターシャ). (2021年6月3日). https://natalie.mu/music/news/430855 2021年6月4日閲覧。 
  18. ^ “劇場版「攻殻機動隊 SAC_2045」11月12日公開、ビジュアル＆特報が解禁”. コミックナタリー. 2021年9月9日閲覧。
  19. ^ “millennium parade「Bon Dance」が東京国際映画祭のフェスティバルソングに”. 音楽ナタリー. 2021年9月22日閲覧。
  20. ^ a b “millennium parade「攻殻機動隊 SAC_2045」シーズン2で再び主題歌「誇りに思います。ただいま!」”. 音楽ナタリー. 2022年2月24日閲覧。
  21. ^ “常田大希インディーズ時代の楽曲が「アンディ・ウォーホル・キョウト」展テーマソングに”. 音楽ナタリー. 2022年6月8日閲覧。
  22. ^ “millennium parade × 椎名林檎、TVアニメ「地獄楽」オープニング主題歌に決定（常田大希＆椎名林檎コメントあり / 動画あり）”. 音楽ナタリー. 2023年2月26日閲覧。
  23. ^ 株式会社インプレス (2023年8月24日). “「攻殻機動隊 SAC_2045 最後の人間」が11月公開。シーズン2のBD BOXも”. AV Watch. 2023年8月24日閲覧。
  24. ^ “ミレパ新曲がPlayStationヘッドフォンのキャンペーンソングに、常田大希がCM出演（動画あり）”. 音楽ナタリー. 2024年5月11日閲覧。
  25. ^ “「MTV VMAJ」米津玄師、あいみょん、King Gnu、ジェネ、BABYMETAL、DISH//、NiziU、JO1ら受賞”. 音楽ナタリー. (2020年10月30日). https://natalie.mu:443/music/news/402798 2024年1月12日閲覧。 
  26. ^ “「MTV VMAJ 2021」星野源、BTS、NiziU、BE:FIRST、ミレパ×Belle、ランぺ、YOASOBIら受賞”. 音楽ナタリー. (2021年10月29日). https://natalie.mu:443/music/news/451399 2024年1月12日閲覧。 
  27. ^ a b c “YOASOBI、藤井風、ミレパ「スペシャアワード」で複数受賞！BMSG、マカえん、LEXらライブ披露”. 音楽ナタリー. (2022年3月16日). https://natalie.mu:443/music/news/469748 2024年1月12日閲覧。 
  28. ^ a b “Official髭男dismとWurtSが「CDショップ大賞」受賞”. 音楽ナタリー. (2022年3月3日). https://natalie.mu/music/news/468030 2024年1月12日閲覧。 
  29. ^ “Mrs. GREEN APPLE「MTV VMAJ」史上初の4冠「本当にうれしいです！」”. 音楽ナタリー. (2023年11月23日). https://natalie.mu:443/music/news/550298 2024年1月12日閲覧。  {{cite news}}: 不明な引数|1=が空白で指定されています。 (説明)⚠
  30. ^ “短編部門 入選作品発表”. 第12回 新千歳空港国際アニメーション映画祭. 2025年11月22日閲覧。
  31. ^ “MILLENNIUM PARADE 『WHO AND HOW TOUR 2024』 開催中止のお詫びとお知らせ”. 2024年8月26日閲覧。
  32. ^ Inc, Natasha. “millennium parade、Awich、D.A.N.出演した「SXSW 2021」の映像配信”. 音楽ナタリー. 2024年1月7日閲覧。
  33. ^ “millennium parade、デジタル音楽フェス＜Splendour XR＞に出演”. BARKS (2021年7月26日). 2024年1月7日閲覧。
  34. ^ “millennium parade、初出演のフジロックで圧巻のステージ！ BelleやKing Gnu・井口理も登場”. THE FIRST TIMES. 2024年1月7日閲覧。
  35. ^ a b “『#014 ヌーミレパーク(仮)』DIRECTED BY PERIMETRON - Ginza Sony Park”. Ginza Sony Park. 2021年2月1日閲覧。
  36. ^ “#014 『ヌーミレパーク(仮)』 DIRECTED BY PERIMETRON”. Sony Park. 2024年1月6日閲覧。
  37. ^ “Sony Park展 KYOTO program”. Sony Park. 2024年1月6日閲覧。
  38. ^ “Ginza Sony Park Project がニューヨークで『MANGA in New York』開催！ー マンガとソニーのテクノロジーを掛け合わせ、新しい体験を生み出す実験的エキシビション”. プレスリリース・ニュースリリース配信シェアNo.1｜PR TIMES (2023年10月6日). 2024年1月6日閲覧。
  39. ^ NYS (2023年11月1日). “MANGA in New York その心は？”. 2024年1月6日閲覧。

外部リンク
常田大希 (Vocal/Guitar/Cello/Programming) - 勢喜遊 (Drums/Sampler) - 新井和輝 (Bass/Synth bass) - 井口理 (Vocal/Keyboard)
スタジオ・アルバム
Srv.Vinci時代

1.Mad me more softly - Mini1.トーキョー・カオティック

King Gnu改名後
シングル
CD
配信限定

1.Flash!!! - 2.白日 - 3.飛行艇 - 4.傘 - 5.泡 - 6.カメレオン - 7.MASCARA - 8.ねっこ - 9.TWILIGHT!!! - 10.SO BAD

ラジオ
関連項目
カテゴリ
所属アーティスト
Sony Music Records
Epic Records Japan
Ki/oon Music
SME Records
Sony Music
Associated Records
Ariola Japan
Sony Music Direct
SACRA MUSIC
関連項目
カテゴリ:ソニー・ミュージックエンタテインメント (日本)

Weblio日本語例文用例辞書
索引トップ 用語の索引 ランキング
辞典・百科事典の検索サービス - Weblio辞書辞典・百科事典の検索サービス - Weblio辞書

「http://」の例文・使い方・用例・文例

Weblio日本語例文用例辞書はプログラムで機械的に例文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。


固有名詞の分類

PHP
 
 bcscale  popen  HTTP  wordwrap  image2wbmp
>>固有名詞    >>製品一覧    >>コンピュータ一覧    >>プログラミング言語一覧


以上の内容はhttps://www.weblio.jp/content/HTTPより取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14