MochiuWiki : SUSE, EC, PCB

「HTTP - HTTPメッセージ」の版間の差分

📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。（旧サイトでは記事を追加しておりません）

← 古い編集
ビジュアルウィキテキスト
 
(同じ利用者による、間の14版が非表示)
14行目: 14行目:
<br>
<br>
また、HTTPはオンデマンドでWebページを更新するために、文書の一部をフェッチするのにも使用される。<br>
また、HTTPはオンデマンドでWebページを更新するために、文書の一部をフェッチするのにも使用される。<br>
<br><br>
== HTTPの基本 ==
==== 単純な構造 ====
HTTP/2のような、HTTPメッセージをフレームにカプセル化することにより複雑さが加わったとしても、HTTPは一般的にシンプルで人間が読めるように設計されている。<br>
<br>
HTTPメッセージは人間が読んで理解することができ、開発者にとってはテストが容易になる。<br>
<br>
==== 拡張可能性 ====
HTTP/1.0で導入されたHTTPヘッダは、このプロトコルの拡張を容易にする。<br>
<br>
クライアントとサーバが新しいヘッダのセマンティクスについて合意するだけで、新しい機能を導入することもできる。<br>
<br>
==== HTTPはステートレス、かつ、非セッションレス ====
HTTPはステートレス (<u>HTTPリクエスト / HTTPレスポンスを１度送受信するごとに接続を切ることをステートレス型と呼ぶ</u>) である。<br>
<br>
同じコネクション上で連続して実行される2つのリクエストの間にはリンクがない。<br>
<br>
例えば、eコマースのショッピングバスケットを使用する場合、特定のページと首尾一貫してやりとりしようとするユーザにとって問題となる見込みがある。<br>
しかし、HTTPのコア自体はステートレスであるが、HTTPクッキーはステートフルなセッションの使用を可能にする。<br>
<br>
ヘッダの拡張性を使用して、HTTPクッキーはワークフローに追加されて、各HTTPリクエストで同じコンテキスト、つまり、同じ状態を共有するセッション生成を可能にする。<br>
<br>
==== HTTPとコネクション ====
コネクションはトランスポート層で制御されるため、基本的にHTTPの範囲外である。<br>
HTTPは基礎となるトランスポートプロトコルがコネクションベースであることを要求しているわけではない。<br>
インターネット上で最も一般的な2つのトランスポートプロトコルの内、TCPは信頼性があり、UDPは信頼性がない。<br>
したがって、HTTPは、コネクションベースであるTCP標準に依存している。<br>
<br>
クライアントとサーバがHTTPリクエスト / レスポンスのペアを交換する前に、TCPコネクションを確立する必要がある。<br>
HTTP/1.0のデフォルトの動作は、HTTPリクエスト / レスポンスのペアごとに別々のTCPコネクションをオープンすることである。<br>
これは、複数のリクエストが連続して送信される場合、1つのTCPコネクションを共有するよりも効率が悪い。<br>
<br>
この欠陥を軽減するために、HTTP/1.1ではパイプライン化（実装が難しいことが判明）と持続的接続が導入された。<br>
基礎となるTCP接続は、Connectionヘッダを使用して部分的に制御できる。<br>
HTTP/2はさらに一歩進み、単一のコネクション上でメッセージを多重化することにより、コネクションをより効率的にする。<br>
<br>
現在では、HTTPにより適したトランスポートプロトコルを設計するための実験が進行中である。<br>
例えば、GoogleはUDPをベースに、より信頼性が高く効率的なトランスポートプロトコルを提供するQUICの実験を行っている。<br>
<br><br>
== HTTPで制御できること ==
HTTPのこの拡張可能な性質は、時代とともに、Webの制御と機能性の向上を可能にしてきた。<br>
キャッシュや認証方法は、HTTPの歴史の初期に扱われていた機能である。<br>
対照的に、オリジン制約を緩和する機能は、2010年代に追加された。<br>
<br>
HTTPで制御可能な一般的な機能を、以下に示す。<br>
* キャッシュ
*: ドキュメントをどのようにキャッシュするかは、HTTPで制御できる。
*: サーバはプロキシやクライアントに、何をどれくらいの期間キャッシュするかを指示することができる。
*: <br>
*: クライアントは中間キャッシュプロキシに、保存されたドキュメントを無視するように指示できる。
* オリジン制約の緩和
*: 盗聴やその他のプライバシー侵害を防ぐため、WebブラウザはWebサイト間の厳格な分離を強制している。
*: 同じオリジンからのページのみが、Webページの全ての情報にアクセスできる。
*: このような制約はサーバにとって負担であるが、HTTPヘッダは、サーバ側でこの厳密な分離を緩和することができ、ドキュメントが異なるドメインからの情報のパッチワークになることを可能にする。
* 認証
*: ページによっては、特定のユーザのみがアクセスできるように保護されている場合がある。
*: BASIC認証は、WWW-Authenticateや同様のヘッダを使用する、または、HTTPクッキーを使用して特定のセッションを設定することにより、HTTPによって提供される場合がある。
* プロキシとトンネリング
*: サーバやクライアントは、ほとんどの場合はイントラネット上にあり、他のコンピュータから本来のIPアドレスを隠している。
*: そして、HTTPリクエストは、このネットワークの障壁を越えるためにプロキシを経由する。
*: <br>
*: また、全てのプロキシがHTTPプロキシというわけではない。
*: 例えば、SOCKSプロトコルは、より低いレベルで動作する。
*: FTPのような他のプロトコルは、これらのプロキシで処理することができる。
* セッション
*: HTTPクッキーを使うことにより、リクエストとサーバの状態を結びつけることができる。
*: 基本的なHTTPは、ステートのないプロトコルであるにもかかわらず、セッションを作成する。
*: これは、eコマースのショッピングのみでなく、ユーザによる出力の設定を可能にするあらゆるサイトに役立つ。
<br><br>
<br><br>


22行目: 93行目:
#: TCPコネクションは、リクエストを送信して、その回答 (レスポンス) を受信するために使用される。
#: TCPコネクションは、リクエストを送信して、その回答 (レスポンス) を受信するために使用される。
#: クライアントは、新しいコネクションを開いたり、既存のコネクションを再利用したり、サーバへの複数のTCPコネクションを開いたりすることができる。
#: クライアントは、新しいコネクションを開いたり、既存のコネクションを再利用したり、サーバへの複数のTCPコネクションを開いたりすることができる。
# HTTPメッセージを送信する。
# HTTPリクエストを送信する。
#: HTTPメッセージ （HTTP/2以前） は人間が読むことができる。
#: HTTPメッセージ （HTTP/2以前） は人間が読むことができる。
#: HTTP/2では、これらの単純なメッセージはフレームにカプセル化され、直接読むことは不可能であるが、原理は変化していない。
#: HTTP/2では、これらの単純なメッセージはフレームにカプセル化され、直接読むことは不可能であるが、原理は変化していない。
30行目: 101行目:
#: <code>Accept-Language: fr</code>
#: <code>Accept-Language: fr</code>
#: <br>
#: <br>
# サーバから送信されたレスポンスを読む。
# WebサーバがHTTPリクエストに対応する処理を行う。
#: <br>
# Webサーバから送信されたレスポンスを読む。<br>クライアント端末は、取得したhtmlファイルを確認して、CSSや画像ファイルが必要な場合は再度Webサーバにリクエストを送信する。
#: <br>
#: <br>
#: <code>HTTP/1.1 200 OK</code>
#: <code>HTTP/1.1 200 OK</code>
44行目: 117行目:
#: <br>
#: <br>
# 接続を閉じる、または、次のリクエストのために再利用する。
# 接続を閉じる、または、次のリクエストのために再利用する。
<br>
[[ファイル:HTTP Connection 1.png|中央]]
<br>
HTTPパイプラインを有効にする時、最初のレスポンスが完全に受信されるのを待たずに、複数のリクエストを送信することができる。<br>
HTTPパイプラインは、古いソフトウェアが最新バージョンと共存している既存のネットワークでは実装が難しいことが判明している。<br>
<br>
HTTPパイプラインは、HTTP/2において、フレーム内でリクエストを多重化する、より堅牢なものに取って代わった。<br>
<br><br>
<br><br>


57行目: 137行目:
==== HTTPリクエストの構成 ====
==== HTTPリクエストの構成 ====
HTTPリクエストは、以下の要素で構成される。<br>
HTTPリクエストは、以下の要素で構成される。<br>
<br>
POST /submit HTTP/1.1              # リクエスト行
Host: example.com                  # ヘッダフィールド
Content-Type: application/json    # ヘッダフィールド
Content-Length: 38                # ヘッダフィールド
                                    # 空行
{"username": "john", "age": 30}    # メッセージボディ
<br>
[[ファイル:HTTP Request 1.png|中央]]
<center>図. HTTPリクエスト</center>
<br>
===== リクエスト行 =====
メソッド、URI、HTTPバージョンを含む。<br>
<br>
* HTTPメソッド
* HTTPメソッド
*: GET、POST、DELETE、OPTIONS、HEADがあり、クライアントが実行する操作を定義する。
*: GET、POST、DELETE、OPTIONS、HEADがあり、クライアントが実行する操作を定義する。
*: 例えば、クライアントがリソースをフェッチする場合 (GET)、または、HTMLフォームの値をポストする場合 (POST) 等がある。
*: 例えば、クライアントがリソースをフェッチする場合 (GET)、または、HTMLフォームの値をポストする場合 (POST) 等がある。
* フェッチするリソースのパス
* フェッチするリソースのパス
*: コンテキストから明らかな要素、例えば、プロトコル (<nowiki>http://</nowiki>)、ドメイン (developer.mozilla.org)、TCPポート (80番) を取り除いたリソースのURLである。
*: コンテキストからプロトコル (<nowiki>http://</nowiki>)、ドメイン (developer.mozilla.org)、TCPポート番号 (80番等) を取り除いたリソースのURLである。
* HTTPプロトコルのバージョン
* HTTPプロトコルのバージョン
<br>
# 例
GET /index.html HTTP/1.1
<br>
===== ヘッダフィールド =====
リクエストの追加情報を含む。<br>
<br>
* サーバに追加情報を伝えるオプションのヘッダ
* サーバに追加情報を伝えるオプションのヘッダ
* POSTのようないくつかのメソッドでは、送信されたリソースを含むレスポンスと似たボディ
* POSTのようないくつかのメソッドでは、送信されたリソースを含むレスポンスと似たボディ
<br>
<br>
# 例
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
<br>
===== 空行 =====
単純な改行であるが、ヘッダフィールドとメッセージボディを区切る重要な要素である。<br>
<br>
===== メッセージボディ =====
主に、POSTリクエスト等でデータを送信する時にパラメータが記述される。<br>
GETリクエストの場合は、空になることが多い。<br>
<br>
# 例 (POSTパラメータ)
{"username": "john", "age": 30}
<br>
==== HTTPレスポンスの構成 ====
==== HTTPレスポンスの構成 ====
HTTPレスポンスは、以下の要素で構成される。<br>
HTTPレスポンスは4つの主要な部分から構成されており、各部分が明確な役割を持つ。<br>
<br>
特にヘッダフィールドは、クライアントがレスポンスを適切に処理するための重要な情報を提供する。<br>
<br>
# HTTPレスポンスの例
HTTP/1.1 200 OK                        # ステータス行
Date: Thu, 14 Nov 2024 12:00:00 GMT    # ヘッダフィールド
Server: Apache/2.4.41 (Unix)            # ヘッダフィールド
Content-Type: text/html; charset=UTF-8  # ヘッダフィールド
Content-Length: 138                    # ヘッダフィールド
                                        # 空行
<nowiki><!DOCTYPE html>                        # ボディ
<html>
  <head>
    <title>Example Page</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html></nowiki>
<br>
[[ファイル:HTTP Response 1.png|中央]]
<center>図. HTTPレスポンス</center>
<br>
===== ステータス行 =====
* HTTPプロトコルのバージョン
* HTTPプロトコルのバージョン
* HTTPリクエストが成功したか否か、および、その理由を示すステータスコード
* ステータスコード (HTTPリクエストが成功の可否、および、その理由が記載)
* ステータスメッセージ、ステータスコードの非正規の短い説明
* ステータスメッセージ、ステータスコードの非正規の短い説明
<br>
下表に、主なHTTPレスポンスのステータスコードの一覧を示す。<br>
* 1xx
*: 情報
* 2xx
*: 正常 (成功)
* 3xx
*: リダイレクト関連
* 4xx
*: クライアント側のエラー
* 5xx
*: サーバ側のエラー
<br>
<center>
{| class="wikitable" | style="background-color:#fefefe;"
|+ HTTPレスポンスのステータスコード
|-
! style="background-color:#66CCFF; width="30%";" | ステータスコード
! style="background-color:#66CCFF; width="70%";" | 説明
|-
| style="text-align: center;" | 200 || OK<br>リクエストが成功して、レスポンスが返されたことを示す。
|-
| style="text-align: center;" | 301 || Moved Parmanently<br>指定したリソースは移動したため、新しい場所から取得することを示す。<br>例えば、Webサイトが恒久的に移転した場合は、この値を設定する。
|-
| style="text-align: center;" | 302 || Moved Temporarily<br>指定したリソースは移動したため、新しい場所から取得することを示す。<br>例えば、Webサイトが一時的に移転した場合は、この値を設定する。
|-
| style="text-align: center;" | 304 || Not Modified<br>指定したファイルは変更されていないため、Webブラウザのキャッシュを表示する。
|-
| style="text-align: center;" | 401 || Unauthorixed<br>認証に失敗したことを示す。
|-
| style="text-align: center;" | 403 || Forbidden<br>アクセス権限が無いことを示す。
|-
| style="text-align: center;" | 404 || Not Found<br>リクエストしたアドレスのページが存在しないことを示す。
|-
| style="text-align: center;" | 500 || Internal Server Error<br>Webサーバにおいて、内部エラーが発生していることを示す。
|-
| style="text-align: center;" | 502 || Bad Gateway<br>ゲートウェイが無効なレスポンスを受信したことを示す。
|-
| style="text-align: center;" | 503 || Service Unavailable<br>サービスが提供できないことを示す。<br>例えば、Webサーバに負荷が掛かりすぎた場合等に表示される。
|-
| style="text-align: center;" | 504 || Gateway Timeout<br>上流からのレスポンスが所定時間内に得られない場合に表示される。
|}
</center>
<br>
===== ヘッダフィールド =====
レスポンスに関する各種メタ情報がある。<br>
<br>
* HTTPリクエストと同様のHTTPヘッダ
* HTTPリクエストと同様のHTTPヘッダ
* オプションとして、取得したリソースを含むボディ
* オプションとして、取得したリソースを含むボディ
<br>
# 例
Date: Thu, 14 Nov 2024 12:00:00 GMT
Server: Apache/2.4.41 (Unix)
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Cache-Control: no-cache
<br>
主要なヘッダフィールドの役割を以下に示す。<br>
* Content-Type
*: メッセージボディのデータ形式を指定
* Content-Length
*: メッセージボディのサイズ (バイト)
* Cache-Control
*: キャッシュの動作を制御
* Set-Cookie
*: クライアントにCookieを設定
* Location
*: リダイレクト先のURLを指定 (3xxステータスで使用)
<br>
===== 空行 =====
単純な改行であるが、ヘッダフィールドとメッセージボディを区切る必須要素である。<br>
<br>
===== メッセージボディ =====
* レスポンスの実際のコンテンツ (HTMLファイルの内容、JSON、画像データ等)
* Content-Typeヘッダで形式を指定する。
<br><br>
== HTTPベースのAPI ==
HTTPをベースにしたAPIで最もよく使用されるものは、Fetch APIである。<br>
これは、JavaScriptからHTTPリクエストを行うことができる。<br>
<br>
Fetch APIは、XMLHttpRequest APIを置き換えるものである。<br>
<br>
もう1つのAPIであるサーバ送信イベントは、HTTPをトランスポートメカニズムとして使用して、サーバがクライアントにイベントを送信できる一方向のサービスである。<br>
EventSourceインタフェースを使用して、クライアントは接続を開き、イベントハンドラを確立する。<br>
<br>
クライアントブラウザ (Webブラウザ) は、HTTPストリーム上に到着したメッセージを自動的に適切なEventオブジェクトに変換する。<br>
そして、既知の場合はイベントのタイプに対して登録されているイベントハンドラに、タイプ固有のイベント・ハンドラが確立されていない場合はonmessageイベントハンドラに、それらを配信する。<br>
<br><br>
== POSTとPUTの違い ==
==== POST （作成・追加） ====
主に、新しいリソースを作成するために使用する。<br>
クライアントはサーバにデータを送信して、サーバはそれを受信して新しいリソースを作成する。<br>
<br>
同じデータを複数回送信しても、常に新しいリソースが作成される。<br>
<br>
==== PUT （更新・置換） ====
既存のリソースを更新するために使用する。<br>
クライアントはサーバに更新するリソースを送信して、サーバはそのデータで既存のリソースを置き換える。<br>
<br>
PUTメソッドは、同じデータを複数回送信しても常に同じ結果が得られるように設計されている。<br>
<br>
==== 安全性 ====
* POST
*: 通常、POSTリクエストは安全ではないと見なされる。
*: つまり、同じリクエストを繰り返しても同じ結果が得られない可能性がある。
*: <br>
* PUT
*: PUTリクエストは一般的に安全であると見なされる。
*: 同じPUTリクエストを複数回送信しても、常に同じ結果が得られるからである。
<br>
==== 冪等性 ====
* POST
*: 通常、POSTは冪等ではない。
*: 同じリクエストを繰り返しても、異なる結果が得られる可能性がある。
* PUT
*: PUTは冪等である。
*: 同じPUTリクエストを複数回送信しても、常に同じ結果が得られる。
<br>
<code>POST</code>は、新しいリソースの作成に使用され、<code>PUT</code>は既存のリソースの更新に使用される。<br>
<code>PUT</code>は冪等性があり、同じリクエストを複数回送信しても同じ結果が得られるため、更新操作に適している。<br>
<br><br>
<br><br>


「http://mochiuwiki.e2.valueserver.jp/index.php?title=HTTP_-_HTTPメッセージ」から取得