HTTPメッセージの構造
HTTPメッセージの構造
メッセージヘッダー 空行(CRLF) メッセージボディ
リクエストライン リクエストヘッダーフィールド 汎用ヘッダーフィールド エンティティヘッダーフィールド その他
ステータスライン レスポンスヘッダーフィールド 汎用ヘッダーフィールド エンティティヘッダーフィールド その他
エンコーディング
HTTPでデータを転送する再、データをエンコーディングすることで転送効率をあげることができる。HTTP通信の基本単位。オクテットシーケンスからなり、通信を解して転送される情報。
リクエスト、レスポンスのペイロードとして転送される情報。エンティティヘッダーフィールドとエンティティボディから構成される。
基本的には、エンティティボディ＝メッセージボディ。転送コーディングでデータを転送する場合は、エンティティボディとメッセージボディは異なる。
Webサーバーが、エンティティを圧縮してから送信する方式。データはクライアント側でデコードする。
主なコンテンツコーディング
gzip(GNU zip)
compress(UNIXの標準的な圧縮)
deflate(zlib)
identity(エンコーディングなし)
エンティティボディを小さく分割してから送信する。チャンク（データの塊）の区切りには、次のチャンクのサイズを１６進数で示した文字列を使う。
HTTP/1.1では、転送コーディングには、チャンク転送コーディングしか定義されていない。
複数の異なる種類のデータを格納する方式。１つのメッセージボディに複数のエンティティを含めて送ることができる。
multipart/form-data
Webフォームからのファイルアップロードなどに使用される。
multipart/byteranges
ステータスコード206(Partial Content)レスポンスメッセージが複数の範囲の内容を含むときに使用される。PDFファイルをダウンロードする際に、よく見かける。
マルチパートをHTTPメッセージで使用するときは、Content-Typeヘッダーフィールドを使う。マルチパートでは、パートごとにヘッダーフィールドが含まれる。パートを入れ子にすること藻できる。
レジューム機能（ダウンロードを銃弾した箇所からダウンロードを再開できる機能）を実現させるため、エンティティの範囲を指定してダウンロードをリクエストすること。
レンジリクエストをするには、Rangeヘッダーフィールドを使い、リソースのバイトレンジを指定する。
GET /test.pdf HTTP/1.1 Host: xxx.com Ranges: bytes=1000-5000 HTTP/1.1 206 Partial Content Content-Range: bytes 1000--5000 Content-Length: 4000
100〜1000バイトのレンジリクエスト Range: bytes=100-1000 100バイト以降すべて Range: bytes=100- 複数レンジリクエスト（最初の１００バイトまで、300〜500バイト） Range: bytes=-100, 300-500
同じコンテンツであっても複数ページを持つWebページで、リクエストの内容によって、適切なページをレスポンスとして返すこと。英語版ブラウザであれば英語のページを返し、日本語晩ブラウザであれば、日本語ページを返すなど。
コンテンツネゴシエーションとは、クライアントとサーバーが提供するリソースの内容について交渉する仕組み。クライアントに最も適したリソースを提供するための仕組み。
コンテンツネゴシエーションでは、以下のリクエストヘッダーフィールドの内容を基準に判断している。
| Accept |
| Accept-Charset |
| Accept-Encoding |
| Accept-Language |
| Content-Language |
| サーバー駆動型ネゴシエーション | サーバーがコンテンツネゴシエーションを行う。サーバー側でリクエストヘッダーフィールドの情報を参考にして自動的に処理をする。 |
| エージェント駆動型ネゴシエーション | クライアントがコンテンツネゴシエーションを行う。ブラウザに表示された選択肢の中から、ユーザーが主導で選択する。JavaScriptを使ったページが自動的に行うものもある。PC用と携帯用ページを切り替えるなど。 |
| トランスペアレントネゴシエーション | サーバー駆動型とエージェント駆動型を組み合わせたもので、サーバーとクライアントがそれぞれコンテンツネゴシエーションを行う。 |
