MochiuWiki : SUSE, EC, PCB

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

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

← 古い編集
ビジュアルウィキテキスト
 
(同じ利用者による、間の9版が非表示)
28行目: 28行目:
<br>
<br>
==== HTTPはステートレス、かつ、非セッションレス ====
==== HTTPはステートレス、かつ、非セッションレス ====
HTTPはステートレスである。<br>
HTTPはステートレス (<u>HTTPリクエスト / HTTPレスポンスを１度送受信するごとに接続を切ることをステートレス型と呼ぶ</u>) である。<br>
<br>
同じコネクション上で連続して実行される2つのリクエストの間にはリンクがない。<br>
同じコネクション上で連続して実行される2つのリクエストの間にはリンクがない。<br>
<br>
<br>
36行目: 37行目:
ヘッダの拡張性を使用して、HTTPクッキーはワークフローに追加されて、各HTTPリクエストで同じコンテキスト、つまり、同じ状態を共有するセッション生成を可能にする。<br>
ヘッダの拡張性を使用して、HTTPクッキーはワークフローに追加されて、各HTTPリクエストで同じコンテキスト、つまり、同じ状態を共有するセッション生成を可能にする。<br>
<br>
<br>
==== HTTPとコネクション ====
==== HTTPとコネクション ====
コネクションはトランスポート層で制御されるため、基本的にHTTPの範囲外である。<br>
コネクションはトランスポート層で制御されるため、基本的にHTTPの範囲外である。<br>
91行目: 93行目:
#: TCPコネクションは、リクエストを送信して、その回答 (レスポンス) を受信するために使用される。
#: TCPコネクションは、リクエストを送信して、その回答 (レスポンス) を受信するために使用される。
#: クライアントは、新しいコネクションを開いたり、既存のコネクションを再利用したり、サーバへの複数のTCPコネクションを開いたりすることができる。
#: クライアントは、新しいコネクションを開いたり、既存のコネクションを再利用したり、サーバへの複数のTCPコネクションを開いたりすることができる。
# HTTPメッセージを送信する。
# HTTPリクエストを送信する。
#: HTTPメッセージ （HTTP/2以前） は人間が読むことができる。
#: HTTPメッセージ （HTTP/2以前） は人間が読むことができる。
#: HTTP/2では、これらの単純なメッセージはフレームにカプセル化され、直接読むことは不可能であるが、原理は変化していない。
#: HTTP/2では、これらの単純なメッセージはフレームにカプセル化され、直接読むことは不可能であるが、原理は変化していない。
99行目: 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>
113行目: 117行目:
#: <br>
#: <br>
# 接続を閉じる、または、次のリクエストのために再利用する。
# 接続を閉じる、または、次のリクエストのために再利用する。
<br>
[[ファイル:HTTP Connection 1.png|中央]]
<br>
<br>
HTTPパイプラインを有効にする時、最初のレスポンスが完全に受信されるのを待たずに、複数のリクエストを送信することができる。<br>
HTTPパイプラインを有効にする時、最初のレスポンスが完全に受信されるのを待たずに、複数のリクエストを送信することができる。<br>
131行目: 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があり、クライアントが実行する操作を定義する。
137行目: 157行目:
*: コンテキストからプロトコル (<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>
[[ファイル:HTTP Request 1.png|中央]]
# 例
<center>図. HTTPリクエスト</center>
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>
<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>
<br>
[[ファイル:HTTP Response 1.png|中央]]
# 例
<center>図. HTTPレスポンス</center>
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>
<br><br>


166行目: 301行目:
クライアントブラウザ (Webブラウザ) は、HTTPストリーム上に到着したメッセージを自動的に適切なEventオブジェクトに変換する。<br>
クライアントブラウザ (Webブラウザ) は、HTTPストリーム上に到着したメッセージを自動的に適切なEventオブジェクトに変換する。<br>
そして、既知の場合はイベントのタイプに対して登録されているイベントハンドラに、タイプ固有のイベント・ハンドラが確立されていない場合はonmessageイベントハンドラに、それらを配信する。<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メッセージ」から取得