『Real World HTTP』という本を読んでいるが、とても面白い。
学んだことをここにメモする。

1.7 URL

URL表記

スキーマ://ユーザ:パスワード@ホスト名:ポート/パス#フラグメント?クエリー

URLを構成する文字はASCII文字列とされている
- 日本語などはUTF-8を使ってURLエンコードする
- ブラウザ上で日本語のURLが表示されるのはデコードしてくれているから
HTTPの仕様上ではURL長の制限はないが、ブラウザ側で制限がかかっていることがある。
当初、URLのドメイン名は半角英数字とハイフンしか使えなかった
- Punycodeというエンコードルールに従えば日本語なども使える
- ただし、実際に送信されるドメイン名はPunycodeによって半角英数字（xn--から始まる文字列）に変換される

1.8 ボディ

Content-Lengthヘッダにボディのバイト数が含まれている。ボディが圧縮されていた場合は圧縮後のバイト数
GET,HEAD,DELETE,OPTIONS,CONNECTメソッドにボディを持たせること自体は可能だが非推奨
- サーバ側はメッセージボディを読み込めるようにしておくべきだがリクエストの処理時にはボディを無視すべき
- ボディを持つ場合、サーバから拒否される可能性もある
TRACEメソッドは「ボディを含めてはいけない」と明記されている。

2.1 x-www-form-urlencoded

シンプルなフォーム送信で利用
リクエストヘッダに"Content-Type: application/x-www-form-urlencoded"を指定
ボディは以下のように「キー=値」の形式で表現され、複数ある場合は「&」で連結される

　name=k-noya&comment=hoge

ブラウザで送信される場合、「アルファベット、数値、一部記号（*-._)」以外の文字はエスケープされる(RFC1866)

2.2 multipart/form-data

ファイルも送信できるフォーム
Content-Typeヘッダに以下を指定

Content-Type: multipart/form-data; boundary=境界文字列

ボディは以下のように境界文字列で区切られた形式となる
- boundary=----WebKitFormBoundaryXXXXと仮定
- "-- + 境界文字列"で始まり、"-- + 境界文字列 + --"で終わる

------WebKitFormBoundaryXXXX
Content-Disposition: form-data; name="name"

k-noya
------WebKitFormBoundaryXXXX
Content-Disposition: form-data; name="comment"

hoge
----WebKitFormBoundaryXXXX--

ファイル送信した場合は以下のような形式となる

------WebKitFormBoundaryXXXX
Content-Disposition: form-data; name="attachment-file"; filename="test.txt"
 Content-Type: text/plain

Hello HTTP

------WebKitFormBoundaryXXXX--

2.4 コンテントネゴシエーション

1リクエストの中で、言語や圧縮方式などの設定をネゴシエートする仕組み
クライアントはAccept系のヘッダを使って要望を伝える
サーバはContent系のヘッダを使って結果を伝える

ネゴシエーション対象	リクエストヘッダ	レスポンスヘッダ
MIMEタイプ	Accept	Content-Type
表示言語	Accept-Language	Content-Language or html内のタグ
キャラクターセット	Accept-Charset	Content-Type
ボディの圧縮方式	Accept-Encoding	Content-Encoding

2.8 キャッシュ

Last-Modified

最初はLast-Modifiedヘッダを使ってキャッシュの有効性を確認していた
- 毎回、If-Modified-Sinceで更新有無を確認しないといけない

Exipre

毎回確認しなくて良いように、Expiresヘッダが登場
- Expireするまでは更新確認不要になった
- ExpireしたらIf-Modified-Sinceで確認

Etag

動的なコンテンツ向けにEtagヘッダが登場
- ハッシュ値を利用するので、「同一URLでもユーザによってコンテンツが異なる場合」に効果的
- If-None-MatchヘッダにEtag値を付けて有効性を確認する。

Cache-Control

Etagと同時期にCache-Controlヘッダが登場
max-age=n, no-cache, no-storeなどキャッシュを制御する仕組みがある。
no-cacheは毎回キャッシュが有効か確認させるもの。「キャッシュさせない」ではない。
- If-Modified-Since or If-None-Matchで毎回確認させる。
- キャッシュしないのはno-store
Cache-Controlはクライアントからプロキシサーバへの要求時にも付加できる（一部のみ）。

Vary

Etagで記載した「同一URLでもユーザによってコンテンツが異なる場合」などに使う
キャッシュサーバはVaryヘッダを見てキャシュを使い分ける必要がある。

例えば、「スマホとPCでコンテンツが異なる」、かつ「ユーザの使用言語によってコンテンツが異なる」という場合には、サーバは以下のVaryヘッダをレスポンスに付加する。

Vary: User-Agent, Accept-Language

4.4 OPTIONS, TRACE, CONNECTメソッド

OPTIONSメソッドはサーバが受付けるメソッド一覧を返す
- OPTIONSメソッドは拒否されることが多い(405 Method Not Allowed)
TRACEメソッドは脆弱性があり、ほぼ使われない
CONNECTはHTTPのプロトコル上に、他のプロトコルを流せるようにする
- https通信を中継する用途で使われることが多い

4.5 プロトコルのアップグレード

ヘッダを使ってHTTP以外のプロトコルにスイッチすることができる
- WebSocketへの切り替えで使われることが多い
- UpgradeヘッダおよびConnectionヘッダを使う

   "Upgrade: websocket"
   "Connection: Upgrade"

アップグレードが可能であれば以下のようなレスポンスが返ってくる

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade

サーバからアップグレードを要求する場合は以下のレスポンスを返すこの場合もクライアントが改めてUpgradeのリクエストを送信する

   HTTP/1.1 426 Upgrade Required
   Upgrade: TLS/1.1
   Connection: Upgrade

4.7 チャンク

データを分割して送信する方式
動画などサイズの大きいファイルを送信する場合にメモリを節約可能
クライアント側ではダウンロードした部分のみを表示するなどの対応が取れる
以下のようなレスポンスとなる
- ボディは16進数のデータサイズから始まる
- データサイズの後に実際のデータを送信
- データサイズに0を指定することでデータ終了を通知

   Content-Type: video/webm
   Transfer-Encoding: chunked
   Trailer: Content-Type

   186a0
   (1000KBデータ)
   186a0
   (1000KBデータ)
   0

チャンク形式の場合のみ末尾（ボディの後）にヘッダを指定可能
- Trailerヘッダで末尾に付与するヘッダを指定

  Trailer: Content-Type

4.8 ボディ送信の確認

ボディ送信の前に受け入れ確認を行う２段階送信が可能になった
- 受け入れ確認には下記ヘッダを付与する必要がある

   Expect: 100-continue

ボディは送信しないが、送信した場合のContent-Lengthヘッダは付与する
- サーバから100 Continueが返ってきたらボディ込みで送信する

5.1 ファイルをダウンロードした後でローカルに保存

ブラウザがファイル種別を判定する際にはMIMEタイプを使う。
レスポンスにContent-Dispositionヘッダがあるとファイル保存する

  Content-Disposition: attachment; filename=filenam.xlsx

RFC6266にしたがってエンコーディングするとUTF-8エンコードされたファイル名も使える。 "filename=filename.xlsx"は後方互換性のため

  Content-Disposition: attachment; filename*=utf-8''ファイル名.xlsx; filename=filename.xlsx

5.2 ダウンロードの中断、再開

コンテンツの範囲指定を使うとダウンロードの中断と再開に対応できる
サーバが範囲指定をサポートしているかはAccept-Rangesヘッダ（レスポンス）を見れば分かる

Accept-Rangeヘッダ	説明
Accept-Ranges: bytes	バイト単位で範囲指定可能
Accept-Ranges: none	範囲指定はサポートしない

ダウンロードを中断して、再開するまでにコンテンツが変わる可能性もあるのでEtagヘッダ（レスポンス）を併用できると良い
範囲指定を行う場合はRangeヘッダを付与する(範囲は0オリジン)
- Rangeヘッダが含まれる場合、レスポンスコードは206 Partial Contentとなる
- Rangeヘッダが無効な場合、レスポンスコードは416 Range Not Satisfiableとなる
- コンテンツが圧縮されている場合は圧縮後の範囲指定と捉えられる

  Range: bytes=1000-1999

Rangeヘッダで複数の範囲指定も可能
- レスポンスのContent-Typeはmultipart/byteranges
- マルチパートフォームと同様のレスポンス

   Range: bytes=500-900,7000-7999

   Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-Type: apllication/pdf
   Content-Range: bytes 500-900/8000

   ...some data...
   --THIS_STRING_SEPARATES
   Content-Type: apllication/pdf
   Content-Range: bytes 7000-7999/8000

   ...some data...
   --THIS_STRING_SEPARATES--

If-Rangeヘッダ（リクエスト）にEtagか日時を設定すると条件付き範囲指定となる
- コンテンツが更新されていない場合は、指定された範囲のコンテンツを返す
- コンテンツが更新されている場合は、コンテンツ全体を返す
- Rangeヘッダと一緒に送る

5.3 XMLHttpRequest

curlコマンドのような機能をJavaScriptから使えるようにしたもの
Javascript内で送受信が完結するので画面をクリアしなくても最新情報を取得可能
画面クリアせずにページを更新したり、時間/タイミングをずらして何度も更新できるアーキテクチャをAjaxと呼ぶ
CometとはXMLHttpRequestを使ってほぼリアルタイムの双方向通信を可能にするテクニック
- ロングポーリングを使っており、サーバはイベント発生までレスポンスを返さない
XMLHttpRequestのセキュリティにはアクセス制限と送信制限がある

制限種別	制限内容
アクセス制限	httponly属性がついたCookieにはアクセスできない
送信制限	ドメイン：基本的には同一ドメインのみアクセス可能
	メソッド：CONNECT, TRACE, TRACK禁止
	ヘッダ：ブラウザ未サポートの圧縮フォーマット指定禁止など

5.7 WebDav

HTTPを拡張した分散ファイルシステム
WebDavの構成要素の一部を以下に記載
- リソース：ファイルのこと
- コレクション：フォルダやディレクトリのこと
- プロパティ：リソースやコレクションのメタデータ（作成日時など）
- ロック：ファイル操作の排他制御用
GET, POST, PUT, DELETEではファイル操作機能が足りないので下記メソッドが追加されている
- COPY
- MOVE
- MKCOL (コレクションの作成)
- LOCK/UNLOCK

参考文献

渋川よしき　著『Real World HTTP』（オライリー・ジャパン発行、ISBN978-4-87311-804-8）
https://www.oreilly.co.jp/books/9784873118048/

[個人メモ] Real World HTTPを読んで学んだこと