HTTPまとめ
webとhttpの歴史
- そもそもは学者の知識共有のためのツールとしてwebのもととなる仕組みが考案された。
- そしてそのWWWを支える仕組みとしてHTTPとHTMLが考案されている。
TCPとIP
それぞれの層での役割
アプリケーション層
トランスポート層
ネットワーク層
- パケットの移動（その経路）を取り扱う層
- ネットワークでは相手にパケットを届けるまでいくつもの経路がありますがその中から1つを決定します。
リンク層
- ネットワークに接続するハードウェア的な部分を扱う
- OSがハードウェアを操作するためのドライバやNIC、そしてケーブルなどの物理的に見える部分がこの層で取り扱う。
以上の4層はデータを送信する際にはユーザもしくはサーバー側から見てアプリケーション層、トランスポート層、ネットワーク層、リンク層の順番で処理されていきます。受信する際はその逆です。
TCP/IPでの通信の流れ
TCP/IP通信をする際の流れをいかに示す。
1.クライアント側のアプリケーション層でどのwebページを見たいかというHTTPリクエストを指示する。
2.次にトランスポート層で通信をしやすいようにばらばらにして通し番号とポート番号をつけてネットワーク層に渡します。
3.ネットワーク層では宛先としてMACアドレスを追加してリンク層に渡します。
4.リンク層でハードウェアの取り決めが行われます。
5.受け取り側は逆にリンク層からたとどってアプリケーション層までたどり着きます。
また、上記のようにそれぞれの層をたどっていく際に層ごとに必要なヘッダが着脱されます。
IP
- IPはネットワーク層のプロトコルの1つで、相手に個々のパケットを届けることが役割である。
- IPにはIPアドレスとMACアドレスという要素があり、IPアドレスは各ノードにつけられたアドレスをさし、MACアドレスはネットワークカードに割り当てられるIDである。
- IPアドレスは変更可能ですがMACアドレスは変更不可である。
- MACアドレスはARPというプロトコルによってアドレス解決され、ARPはIPアドレスをもとにMACアドレスを取得する
信頼性が高いTCP
- TCPはトランスポート層にあたるプロトコルで、スリーウェイハンドシェイクと呼ばれる手法によって信頼性の高いデータ通信を行っている。
- スリーウェイハンドシェイクでは【SYN】と【ACK】というTCPフラグが使われる。
フラグを使った通信の流れを以下に示します。
- 【SYK】で相手に接続するとともパケットを送ります。
- 受信側は【SYK/ACK】とともにパケットを受け取った胸を伝えます。
- 最後に送信側が【ACK】のフラグを返すことで通信が終了したことを示します。
上記の過程がどこかで途絶えた場合TCPはパケットを再送して同じ手順を行います。
URI
- URIとはスキームで表すことができるリソースを識別するための識別子である。
- スキームとはリソースを得るための手段の名前付け方法のことです。
- URIは「スキーム名」、「資格情報（クレデンシャル）」、「サーバーのアドレス」、「サーバーのポート」、「階層的なファイルパス」、「クエリー文字列」、「フラグメント修飾子」などから成り立ちます。
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1の場合の
http =「スキーム名」
user:pass =「資格情報(クレデンシャル)」
www.example.jp = サーバーのアドレス
80 =「ポート番号」
/dir/index.htm = 階層的なファイルパス
uid=1 =「クエリー文字列」
ch1 =「修飾子」
スキーマ名
- リソースを取得するために使うプロトコルを指示する。
- "data"や"javascript"のようにプログラムを指定することもできる。
資格情報（オプション）
- サーバーからリソースを取得するのに必要な資格情報。
- オプション扱い。
サーバーのポート番号（オプション）
- サーバーの接続先となるポート番号。
- オプション扱い。
階層的なファイルパス
- リソースを識別するためのサーバー上のファイルパス
クエリー文字列（オプション）
- ファイルパスで指定されたリソースに任意のパラメーターを渡すためのもの。
- オプション扱い
フラグメント修飾子（オプション）
- 取得したリソースのサブリソースを示すのに使われる。
- サブリソースとはドキュメント内の途中の位置などをさす。
HTTPは状態を保持しないステートレスなプロトコル
- HTTPはリクエストごとに新しいレスポンスが生まれ、過去のリクエストやレスポンスの状態は一切保持しない。
- 別ページに行ってもログイン状態を維持したい場合はCookkieという技術（後述）でその課題が解決される。
HTTPメソッド
- HTTPメソッドはサーバーに支持を与えるためのものである。
メソッドの種類
GET : リソースの取得
POST : エンティティボディの転送
- GETメソッドと類似しているが、エンティティボディー転送の目的で使用される。
- GETでもエンティティボディーは送信は可能であるが、POSTが一般的に使われる。
- POSTメソッドの目的はレスポンスによるエンティティの取得ではない。
PUT : ファイルの転送
- ファイルを転送するために使われる。
- このPUTメソッドそのものに認証機能がないため、セキュリティ上に問題がある。
- Webアプリケーションなどによる認証機能の組み合わせや、RWST（Representational State Trancefer）という設計様式を使う場合に利用される。
HEAD : メッセージヘッダーの取得
- HEADメソッドはGETと同様の機能ですが、URLの有効性やリソースの更新時間を確かめる目的などで使われる。
DELEATE : ファイルの削除
- ファイルの削除を行うためのメソッド。
- PUT同様メソッドそのものに認証機能はない。
- PUTと同様な場面で使われる。
OPTION : サポートしているメソッドの問い合わせ
タイトル通り
TARANCE : 経路の調査
- Webサーバーに接続して自分に通信を折り返してもらうループバックを起す。
- リクエスト送信の際"Max-Forwards"という数値をヘッダーフィールドに定め、サーバーを通過するごとにその数を減らしていきます。
- 0になったところを最後とし、最後にリクエストを受け取ったサーバーはステータスコード200のokを返す。
- XSTという攻撃に利用されることによって現在では使われていません。
CONNECT : プロキシへのトンネリング要求
持続的な接続で通信量を節約
パイプライン化
Cokkieを使った状態管理
- ステートレスなHTTP通信で、クライアント側に以前までのやり取りの状態を保存してもらうためCokkieを使う。
- HTTPヘッダのSet-Cokkieでクッキーをクライアントに送る。
- 保存したCokkieをクライアントはサーバーに送り、サーバーはそのCokkie情報から以前までの状態を認識する。
第3章HTTPの情報はHTTPメッセージにある
HTTPメッセージ
- HTTPリクエストとHTTPレスポンス
- 大きくメッセージヘッダとメッセージボディから成り立つ
リクエストメッセージとレスポンスメッセージの構造
リクエストメッセージ
- メッセージヘッダー
- メッセージボディ
レスポンスメッセージ
- メッセージヘッダー
- ステータスライン
- レスポンスのステータスコードとHTTPのバージョン
- レスポンスヘッダフィールド
- レスポンスの諸条件や属性を表す各種ヘッダ
- 一般ヘッダフィールド
- ステータスライン
- メッセージボディ
エンコーディングで転送効率を上げる
メッセージボディとエンティティボディの違い
メッセージとエンティティとは
- メッセージ
- HTTP通信での基本単位
- オクテットシーケンス（8bit）からなり、通信を介して転送
- エンティティ
違い
- メッセージボディの役割はリクエストやレスポンスに関するエンティティボディを運ぶこと
- 基本的には「メッセージボディ＝エンティティボディ」
- 転送コーディングで送る場合はエンティティボディの内容が変わるため≠
圧縮して送るコンテンツコーディング
主なコンテンツコーディングの種類
分解して送るチャンクエンコーディング
- HTTP通信ではリクエストしたリソースのすべてのエンティティボディの転送が完了しないとブラウザー表示されない。
- 大きなデータを転送する場合はデータをいくつかに分けることで少しずつ表示できる。
- エンティティボディを分割する機能をチャンク転送コーディングと呼ぶ
- チャンク転送コーディングでは区切りのサインとして次のチャンクサイズを16進数で示したものを使う
- エンティティボディの最後には”０（CR＋LF）”を書いている
使われてるところ
- Webページとか開く際に画像が部分部分で表示されているのはチャンクエンコーディングで分割して送られるから
複数の形式のデータを送れるマルチパート
- メールにはMIMEと呼ばれる複数種のデータを扱うための仕組みがあり、マルチパートと呼ばれる複数の形式のデータを格納する方式を使っている。
- HTTPにもこのマルチパートに対応しており、1つのメッセージボディの中に複数のエンティティを含めて転送することができる。
- マルチパートの区切り文字列はHTTPヘッダのContent-Typeヘッダーフィールドのboundaryに指定する。
- 実際の区切りは区切り文字列プラス”--”になる
COntent-Type:Multipart/formdata; boundary=AaB03x (改行) --AaB03x Content-Type:application/pdf Content-Renge:byte 7000-7999/8000 (改行) （データ） --AaB03x Content-Type:application/pdf Content-Renge:byte... (改行) (別のデータ) --AaB03x--
マルチパートの種類
- Multipart/form-data
- webフォームからファイルアップロードに使用される
- Multipart/byteranges
- ステータスこーでお206(Partial COntent)レスポンスメッセージが複数の内容を含むときに使用される。
一部だけもらえるレンジリクエスト
- インターネットが普及する以前は大きなデータを送ってもらっている最中にコネクションが切断されると最初からやり直しになっていた。
- 現在はレジュームと呼ばれる機能でダウンロードしたところから再開できる。
- レジュームを行うためには部分的に送ってもらう範囲を指定することが必要であり、その範囲指定したリクエストをレンジリクエストという。
- レンジリクエストに対するレスポンスのステータスコードは206（Partial Content）
- サーバーがレンジリクエストに対応していない場合は200 OKのステータスコードが返され、完全なエンティティが返される。
最適なコンテンツを返すコンテンツネゴシエーション
コンテンツネゴシエーションの種類
サーバー駆動型ネゴシエーション
エージェント駆動型ネゴシエーション
- クライアント側でコンテンツネゴシエーションを行う方式
- ブラウザーに表示された選択肢からユーザーが主導で選択する。
- JavaScriptで自動的に行うものもある。
- たとえば、PC用とスマフォ用のWebページを切り替えるなど。
トランスペアレントネゴシエーション
第4章 結果を伝えるHTTPステータスコード
ステータスコードはサーバーからのリクエスト結果を伝える。
- クライアントからのリクエストに対して、結果を示すのがステータスコードである。
- ステータスコードは200 OKのように3ケタの数字と説明から成り立つ。
- 最初の1桁（百の位の部分）でレスポンスの種類を表している。
| ステータスコード | クラス | 説明 |
|---|---|---|
| 1XX | Infomational | ステータスが受け入れられて処理中 |
| 2XX | Success | リクエストされた処理が正常に完了した |
| 3XX | Redirection | リクエストが完了するには追加動作が必要 |
| 4XX | Client Error | サーバーがリクエストを理解できなかった |
| 5XX | Server Error | サーバーがリクエストの処理に失敗した |
2XX 成功（Success）
2XXのレスポンスはリクエストが正常に処理されたことを示す。
200 OK
- リクエストをサーバーが正常に処理したことを表す。
204 NO Content
- リクエストに対する処理は成功しているが、レスポンスにエンティティボディが含まれない。
- クライアントからサーバーに情報が送られるだけでよく、クライアントに新たな情報を送る必要がない場合に使われる
206 Partial Content
3XX リダイレクト(Redirection)
301 Moved Permanently
302 Found
303 SeeOther
- リクエストに対するリソールが別のURIにあり、GETメソッドで再取得を行ってほしい場合のレスポンス
- 基本的には302 Foundと同じであるが、リダイレクト先をGETメソッドで取得することが明確になっている。
304 Not Modified
- クライアントが条件付きリクエスト(GETメソッドによるリクエストメッセージにIF-Match, If-Modified, IF-None-Match, If-Range, If-Unmodiged-Sinceのいずれかがヘッダーフィールドを含んでいる場合のリクエスト)を行ったときアクセスは許可されたが、条件が満たされなかった場合のレスポンス
- 3XXに部類されるがリダイレクトとは毛色が違う。
307 Temporary Redirect
- 302 Foundと同じ意味を持つが？
4XX クライアントエラー
- 4XXレスポンスは、クライアントが原因でエラーが発生していることを示す。
400 Bad Request
401 Unauthoried
- 送信されたリクエストには認証が必要であることを示す。
- 2度目以降の401 Unautoriedのレスポンスは認証失敗を表す。
- 401を含んだレスポンスを返す場合にはリクエストされたリソースに適用できるWWW-Authenticateヘッダーフィールドを含む必要がある。
- ブラウザで最初に401レスポンスを受け取った場合は認証のためのダイアログが表示される。
403 Forbidden
- リクエストされたリソースへのアクセスが拒否されたことを表す。
- サーバー側は拒否の理由を明らかにする必要はない。
- 明らかにする場合はエンティティボディに記載し、ユーザー側に表示する。
- ファイルシステムのパーみんしょんが与えられていない場合や、アクセス権限の何らかの問題がある場合がある
5XX サーバーエラー
- 5XXレスポンスはサーバーが原因でエラーが発生していることを示す。
500 Internal Server Error
- サーバーがリクエストを実行する際にエラーが起きたことを示している。
- Webアプリケーションにエラーがある場合や一時的な状態のこともある。
503 Service Unavailable
- サーバーが一時的な過負荷、もしくはメンテナンスのため現在リクエストを処理できないことを表す。
- 解消時間がわかっている場合はRetry-Afterヘッダーフィールドにその時間を記載し、クライアントに伝えることが望ましい。
HTTPと連携するWebサーバー
- Webサーバーは1つのサーバーで複数のドメインを立ち上げることができる。
- 通信の中継サーバーとして、通信効率を上げることができる。
1台で複数ドメインを実現するバーチャルホスト
- HTTP/1.1では1つのサーバーに複数のWebサイトを立ち上げることができる。
- バーチャルホストという機能を使いサーバー1台に対し仮想的に複数台あるように扱うことができる。
- バーチャルホストの仕組みがあるため、HTTPリクエストを送る場合は、ホスト名、ドメイン名を完全に含んだURIの指定か、Hostヘッダーフィールドでの指定が必ず必要となる（DNSより、ドメイン名がIPアドレスに変換されてアクセスされるから）。（？）
通信を中継するプログラム : プロキシ、ゲートウェイ、トンネル
- HTTPではクライアントとサーバー以外にプロキシ(Proxy)、ゲートウェイ(Geteway)、トンネル(Tunnel)といった通信を中継するプログラムやサーバーが存在する。
プロキシ(Proxy)
- サーバーとクライアントの両方の役割をする中継プログラム
- クライアントからのリクエストをサーバーに、サーバーからのレスポンスをクライアントに渡す。
ゲートウェイ(Geteway)
トンネル(Tunnel)
- 2つの離れたクライアントとサーバーの間で中継することで、2台の接続を取り持つ中継プログラム
プロキシ
- 基本的なプロキシサーバーの動作はクライアントから受け取ったリクエストをURIを変更せずに別のサーバーに転送すること。
- リソースを持ったサーバーのことをオリジンサーバーと呼び、オリジンサーバーからのレスポンスはまたプロキシサーバーを経由してクライアントに受け渡される。
- HTTP通信においてプロキシサーバーは複数台経由することもできる。
- 中継の際にはViaヘッダーフィールドにホストの情報を追加してゆく。
- プロキシサーバーの役割
- キャッシュを用いてネットワーク帯域などの効率をよくする。
- 組織で特定のWebサイトに対してアクセス制限をかけたりログをとったりして、ポリシーをっ徹底させる目的として使用される。
キャッシングプロキシ
- プロキシでレスポンスを中継する際に、プロキシサーバー上にリソースのコピーをキャッシュしておくタイプのプロキシ
透過型プロキシ
- プロキシでリクエストやレスポンスを中継する際にメッセージに何も変更を加えないプロキシ
- 逆にメッセージに何らかの変更を加えるタイプのプロキシを非透過型プロキシ
ゲートウェイ
- 動作はプロキシによく似ている。
- ゲートウェイの場合にはその先にあるサーバーはHTTPサーバー以外のサービスを提供するサーバーである。
リクエスト時: クライアント⇒HTTPリクエスト⇒ゲートウェイ⇒HTTP以外の通信⇒HTTP以外のサーバー レスポンス時: HTTP以外のサーバー⇒HTTP以外の通信ゲートウェイ⇒HTTPリクエスト⇒クライアント
- クライアントとゲートウェイ間を暗号化でセキュアに通信することで通信の安全性を高める役割などをしている。
- 利用例
トンネル
- 要求に応じで別サーバーとの通信路を確立する。
- SSLなどによる暗号化通信を施し、クライアントとサーバーが安全に通信を行う目的で用いられる。
- トンネルそのものはHTTPリクエストを解釈せずにそのまま先のサーバーに中継する。
リソースを保管するキャッシュ
- キャッシュはプロキシサーバーやクライアントのローカルディスクに保存されたリソースのコピーのことを指す。
- キャッシュを使うことでリソースを持ったサーバーへのアクセスを減らすことができる。
- キャッシュサーバーはプロキシサーバーの一種でキャッシングプロキシに部類される。
- キャッシュサーバーはオリジンサーバーからのレスポンスを中継する際にそのリソースをコピーして保存しておく。
キャッシュには有効期限がある。
- キャッシュサーバーにキャッシュがあるからと言って、同じリソースへのリクエストに対して常にキャッシュを返すとは限らない。
- クライアントからの要求やキャッシュの有効期間などによってオリジンサーバーに有効性を確認しに行ったり、新たなリソースを再度取得しに行ったりする。
クライアント側にもキャッシュがある。
- キャッシュはキャッシュサーバーだけではなくクライアントが使用しているブラウザーが持っている場合もある。
- キャッシュサーバーと同じくリソースが古いと判断した場合はオリジンサーバーに有効性を確認しに行ったり、新たなリソースを再度取得しに行ったりすることがある。
6章 HTTPヘッダー
HTTPメッセージヘッダー
| メッセージヘッダー |
|---|
| 空行(CR+LF) |
| メッセージボディ |
リクエストメッセージヘッダの構成
レスポンスメッセージヘッダの構成
- ステータスライン
- HTTPバージョン
- ステータスコード
- レスポンスヘッダーフィールド
- エンティティヘッダーフィールド
- その他
HTTPヘッダーフィールド
HTTPヘッダーフィールドは重要な情報を伝える
- リクエストにもレスポンスにも使われており重要な情報を伝える役割を果たしている。
- メッセージボディのサイズや、使用している言語、認証情報などをブラウザやサーバーに提供するために使用される。
HTTPヘッダーフィールドの構造
- HTTPヘッダーフィールドはヘッダーフィールド名とフィールド値から構成されコロンで区切られている。
ex. ヘッダーフィールド名：フィールド値 Content-Type:text/html
- ヘッダーフィールド名はUS-ASCII文字で構成される。
- フィールド値は1つのヘッダーフィールドに対して複数持つことができる。
4種類のHTTPヘッダーフィールド
- HTTPヘッダーフィールドはその用途に合わせて4種類に分類される。
一般ヘッダーフィールド
- HTTPヘッダーフィールドは、リクエストとレスポンスその両方で使用されるヘッダー
リクエストヘッダーフィールド
レスポンスヘッダーフィールド
- サーバーからクライアント側に対して送信されるレスポンスメッセージで使用されるヘッダー
- レスポンスの付加情報やサーバーの情報、クライアントへの付加情報などの要求などを付加する。
エンティティヘッダー
- リクエストメッセージとレスポンスメッセージに含まれるエンティティに使用されるヘッダー
- コンテンツの更新時間などエンティティに関する情報を付加する。
エンドトゥエンドヘッダーとホップバイホップヘッダー
エンドトゥエンドヘッダー＊
- 送信元から送信先まで
ポップバイポップヘッダー＊
HTTTP/1.1ヘッダーフィールド
- リクエストとレスポンスどちらでも利用されるヘッダー
Chashe-Control
- ディレクティブと呼ばれるコマンドを指定することでキャッシュの動作を指定する。
- 指定するディレクティブにはパラメーターがある元のないものがある
- 複数のディレクティブを指定する場合はカンマ","で区切る
Chashe-Control
キャッシュリクエストディレクティブ
| ディレクティブ | パラメーター | 説明 |
|---|---|---|
| no-chache | なし | オリジンサーバーへの強制的な再検証 |
| no-store | なし | キャッシュはリクエスト、レスポンスの一部を保存してはいけない |
| max-age＝[秒] | 必須 | レスポンスの最大Age値 |
| max-stale＝[秒] | 省略可能 | 期限切れのレスポンスを受け入れる |
| min-fresh＝[秒] | なし | 指定した時間は新鮮さがあるレスポンスを望む |
| no-transform | なし | プロキシはメディアタイプを変換してはならない |
| only-if-chached | なし | キャッシュからリソースを取得 |
| chach-extension | - | 新しいディレクティブのためのトークン |
キャッシュレスポンスディレクティブ
| ディレクティブ | パラメーター | 説明 |
|---|---|---|
| public | なし | どこかにレスポンスキャッシュが可能 |
| private | 省略可能 | 特定のユーザーに対してのみレスポンス |
| no-chach | 省略可能 | 有効性の再確認なしではキャッシュは使用してはならない |
| no-store | なし | キャッシュはリクエスト、レスポンスの一部を保存してはならない |
| no-transform | なし | プロキシはメディアタイプを変更してはならない |
| must-revalidate | なし | キャッシュは可能だが、オリジンサーバーにリソースの再確認を要求する |
| proxy-revalidate | なし | 中間キャッシュサーバーに対し、キャッシュしたレスポンスの有効性を再確認を要請 |
| max-age=[秒] | 必須 | レスポンスの最大Age値 |
| s-maxage=[秒] | 必須 | 共有キャッシュサーバーのレスポンス最大Age値 |
| cache-extension | - | 新しいディレクティブのためのトークン(？) |
Connection
- Connectionヘッダーフィールドには2つの役割がある。
- プロキシに対してそれ以上転送しないヘッダーフィールドの指定
- Connection:"それ以上転送しないヘッダーフィールド名"
- 持続的接続の管理
- プロキシに対してそれ以上転送しないヘッダーフィールドの指定
持続的接続の管理に使われるフィールド値
| Connecitonのフィールド値 | 説明 |
|---|---|
| Close | HTTP/1.1で持続的接続がデフォルトになっているため、明示的に接続を閉じたい場合に使用する |
| Keep-Alive | HTTP/1.1以前のバージョンで持続接続がデフォルトでないため、明示的に持続接続を行うためのフィールド値 |
Trailer
- メッセージボディの後に記載されているヘッダーフィールドをあらかじめ伝えることができる。
Transfer-Encoding
Via
- プロキシ、もしくはゲートウェイにおいて自サーバーの情報をViaヘッダーフィールドに追加する
- 経路を知るために使用される。
Warning
- レスポンスに関する追加情報を伝える
- 基本的にはキャッシュに関する問題の警告をユーザーにつたえる。
- Warning:[警告コード] [警告したホスト:ポート番号] "[警告文]" ([日時])
| コード | 警告文 | 説明 |
|---|---|---|
| 110 | Response is stale | プロキシが有効期限切れのリソースを返した |
| 111 | Revalidation failed | プロキシがリソースの有効性の再確認に失敗した |
| 112 | Disconnection operation | プロキシがネットワークから恋に切断されている |
| 113 | Heuristic Expriration | レスポンスが24時間以上経過している場合（キャッシュの有効期限が24時間以上に設定している場合） |
| 199 | Miscellaneous waring | 任意の警告文 |
| 214 | Tranceform applied | プロキシがエンコーディングやメディアタイプなどに対して何らかの処理を行った場合 |
| Miscellaneous persistent waring | 任意の警告文 |
リクエストヘッダーフィールド
- クライアント側からサーバー側に対して送信される。
- リクエストの付加情報やクライアントの情報、レスポンスのコンテンツに関する優先度などを付加します。
Accept
- ユーザーエージェントが処理することができるメディアタイプと、メディアタイプの相対的な優先度を伝えるために使用される。
- メディアタイプ一覧
Accept-Charset
- ユーザーエージェントが処理することができる文字セットと、文字の相対的な優先度を伝えるために使用される。
- 文字セットは一度に複数扱うことが可能
- サーバー駆動型ネゴシエーションに利用される
Accept-Encoding
- ユーザーエージェントが処理することができるコンテンツコーディングとコンテンツコーディングの相対的な優先度を伝えるために使用される。
- コンテンツコーディングは一度に複数指定できる。
- Acceptヘッダーフィールドと同じで品質係数によって相対的な優先度を指定する。
- "＊" (ワイルドカード)を指定するとあらゆるエンコーディングフォーマットを示す。
- コンテンツコーディングの例
Accept-language
Authorization
Expect
- クライアントがサーバーに特定の振る舞いを要求していることを伝える。
- 期待に応えられない場合は417 Expectation Failedを返す。
- クライアントは希望する拡張をこのヘッダーフィールドで伝えることができる。
- HTTP/1.1では"100-continue"（ステータスコード 100 COntinue）しか定義されていない。
- ステータスコード100レスポンスを待つクライアントは、リクエスト時にExpect 100-continueと指定する必要がある。
From
- ユーザーエージェントを使っているユーザーのメールアドレスを伝える。
- エージェントを使用する場合はなるべく使うべきである(？)
- User-Agentヘッダーフィールドにメールアドレスを含んでいるものもある。
