「Web を支える技術」を読む

URI の仕様

URI (Uniform Resource Identifier)

• URL (Uniform Resource Location) と URN (Uniform Resource Name) をあわせた呼びかた
• 構文 (http://user:pass@example.com:8000/users/1/items?q=test&debug=true#n10)
  • URIスキーム：http
  • ユーザー情報：user:pass
  • ホスト名：example.com
  • ポート番号：8000
  • パス：/users/1/items
  • クエリパラメーター：q=test&debug=true
  • URIフラグメント：#n10

URI のパスで使用できる文字

• アルファベット： A-Za-z
• 数字：0-9
• 記号：-.~:@!$&'()

%エンコーディング

• URI のパスで使用できない文字は文字を構成するバイト列の16進数を%xx で表現
• xx は大文字でも小文字でも同じ意味を持つが URI の仕様では大文字を推奨
• % 自体もエンコーディングで使用するので %25 と表記する
• エンコードはUTF-8を使用することを推奨

URI の設計

クールな URI は変わらない

変わりにくくするには

• 実装依存の名前を含めない
  • プログラミング言語
    • http://example.jp/cgi-bin/login.pl
  • 拡張子
    • http://example.jp/cgi-bin/login__.pl__
  • メソッド名
    • http://example.jp/home.jsp?action=showPage
  • セッション名
    • http://example.jp/home.jsp?jsessionid=12345678
• リソース名を名詞にする
  • http://example.jp/sample/people/show/123 -> http://example.jp/sample/people/123
  • フレームワークが実装依存の URI を生成する場合はユーザーに見せる URI と 内部的に利用する URI を分ける

URI のユーザビリティー

• シンプルでユーザーにわかりやすいものを使うと良い

URI の設計テクニック

• コンテントネゴシエーション
  • 1つのリソースを複数の言語やファイルタイプなどで返す
  • 明示的にリソースの言語を URI で表現する
    • Accept-Lnaguage ヘッダーで判断すると切り替えたいときにブラウザの設定を変更しなくてはならない

HTTP の基本

4階層モデル

• アプリケーション層
  • HTTP, NTP, SSH
• トランスポート層
  • UDP, TCP
• インターネット層
  • IP
• ネットワークインターフェイス層
  • イーサネット

HTTP メッセージ

• リクエストメッセージとレスポンスメッセージをまとめた呼称

• HTTPメッセージの構造

  • スタートライン
    • リクエストライン or ステータスライン
  • ヘッダー(省略可）
  • 空行
  • ボディ(省略可）

リクエストメッセージ

POST /list HTTP/1.1
Host: example.jp
ContentType:text/plain; charset=utf8

こんにちは！

• リクエストライン
  • 1行目：メソッド, リクエストURI, プロトコルバージョン
  • 2行目：Host: 実際のホスト名
    • 相対パスでも絶対パスでも可
      • プロキシへのリクエストの場合は絶対URI

レスポンスメッセージ

HTTP/1.1 201 Created
ContentType: text/plain;charset=utf8
Location: http://example.jp/list/item5

こんにちは！

HTTP メソッド

冪等性と安全

• GET,HEAD

  • 冪等かつ安全

• PUT,DELETE

  • 冪等だが安全でない

• POST

  • 冪等でも安全でもない

• 冪等

  • 何回行ってもリソース状態が同じ
    • Delete で削除に成功して 200 OK が返ってきて2回目ですでに削除済みで 404 Not Found が返ってきてもリソースの状態は同じなので冪等

• 安全

  • 操作対象のリソース状態を変化させない
    • GET でログが出力されるなどがあっても操作対象のリソースが変化されるわけでなければ安全

ヘッダー

• HTTP ヘッダの文字コードは ISO 8859-1でなくてはならない
• Date は GMT で表現

Contet-Type

• [タイプ]/[サブタイプ]
  • タイプ
    • text
    • image
    • audio
    • video
    • application
    • multipart
    • message
    • model
    • example
  • サブタイプ
    • IANA から登録可能
    • 「x-」プレフィクスをつけると独自のサブタイプも作れる
• charaset
  • デフォルトは ISO 8859-1
  • xml のように文書自体にエンコーディングが指定できる場合でも charaset が優先される

ContentLength

メッセージがボディーを持っている場合、ボディーのサイズを 10進数のバイトで示す

• Transfer-Encoding
  • 値は chunked のみ
  • 最終的な値がわからない動的なコンテンツを返すときに使用する

認証

• HTTP が規定している認証方式
  • Basic 認証
    • Authorization ヘッダー にBasic につづいてユーザー名とパスワードを Base64にエンコードした文字列を設定する
  • Digest 認証
    • リクエストのたびに 401 Unauthorized レスポンスがかえるためあまり普及していない
• 認証の要求方法
  • ステータスコード 401 と WWW-Authenticate ヘッダーを使用する
• realm
  • リソースが属している URI 空間
  • 同じ URI 空間に属するリソースには同じ認証情報を送信できる
    • 毎回 401 Unauthorized がかえるのを避けられる

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Example.jp"

• OpenID と Oauth
  • OpenID： シングルサインオン
  • OAuth：Web サービス同士の連携ができる

キャッシュ

• Pragma
  • no-cache のみ
    • キャッシュさせない
    • HTTP/1.0 の下位互換のために使用
    • https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Pragma
• Expires
  • キャッシュの有効期限
  • GMT で指定
  • 最長でも1年後の日時を入れることを推奨
• Cache-Control
  • HTTP/1.1 で追加
  • Pragma と Expires の代用が可能
    • Cache−Control: no-cache
    • Cache-Control: max-age: 86400
      • 相対時間で指定
  • 条件付き取得
    • If-Modified-SInce
      • リソースの更新日時を条件にする
        • レスポンスの Last-Modified ヘッダーと比較
      • GMT で指定
    • If-None-Match
      • ETag が指定した値とマッチするかしないかを条件にする
        • レスポンスの ETag ヘッダーと比較

その他

• Content-Disposition
  • ファイル名を指定する
  • 日本語を指定したい場合は RFC 2047 / RFC 2231 に従って Bエンコーディング(BASE64エンコーディング)が必要
    • サーバー側とクライアントで実装すれば % エンコーディングでも可能
  • そもそも厳密対応しようとするとエンコード後の文字数が78文字以内に収める必要がある
  • 自分メモ
    • FormData の append で File を追加した場合もこのヘッダにファイル名が設定されるため、そのままだと文字化けしてしまう。
    • 日本語のファイル名の場合は fileName にエンコードしたファイル名を設定する必要がある
    • https://developer.mozilla.org/ja/docs/Web/API/FormData/append