HTTPヘッダの重要性
- メッセージボディに対する付加的な情報(メタデータ)を表現
- クライアントとサーバはヘッダを見てメッセージに対する挙動を決定する
- メディアタイプなや言語タグなど、アプリケーションのフレームワークでなく、実装者が設定するヘッダも多い
HTTPヘッダの生い立ち
日時
言語タグ
- Content-Language
- リソース表現の自然言語を指定する
- ISO639で定義された言語コードとISO3166で定義された地域コードを指定
例)「ja-JP」
Content-Lengthとチャンク転送
認証
HTTP認証方式
- リソースへのアクセス制御がかかっている場合のクライアントへの認証情報通知
- ステータスコード
- 401 Unauthorized
- このリソースに対してのアクセスには認証が必要
- WWW-Authenticateヘッダ
- 認証方式
- URI空間
→URI中にあるパス以下のコト
- 同じURI空間に属するリソースには同じ認証情報を送信できる
HTTPS
- HTTP、SSL/TLSを組み合わせた通信の総称
- 通信路を暗号化して通信データを保護し、盗聴を防ぐ目的で利用する
Basic認証
- ユーザー名とパスワードをAuthorizationに入れれてリクエスト
- ユーザー名とパスワードは「:」で連結し、Base64エンコーディング
- 簡単にデコード可能なので、平文がネットワーク上に流れている
- 許容されるセキュリティ強度か、HTTPS通信(SSL、TLS)で暗号化するなどの検討が必要
Digest認証
- セキュアな認証方式
- 認証なしでリクエストして、レスポンス情報から認証情報を生成し、再送信する
チャレンジ
- リクエスト
- レスポンス
nonce
- number used once
- リクエストごとに変化する文字列
- タイムスタンプ、パスワード(サーバーのみが知りえる情報)などから生成
- 有効期間を狭めるためにタイムスタンプを活用
qop
- quality of protection
- 「auth」 or 「auth-init」が指定
- クライアントのメッセージダイジェスト作成方法に影響あり
- auth:メソッドとURIからメッセージダイジェストを作成
- auth-init:メソッドとURI、メッセージボディからメッセージダイジェストを作成
- POSTやPUTの場合、メッセージ全体が改ざんされていないことを保証
opaque
- クライアントが推測できない文字列
- URI空間ごとに共通
再送信
- ①ユーザー名、realm、パスワードパスワードを「:」で連結し、MD5ハッシュ値を求める
- ②メソッドとURIのパスを「:」で連結し、MD5ハッシュ値を求める
- ③①、サーバーから得たnonce、クライアントかがnonceを送った回数、クライアントが生成したnonce、qopの値を「:」で連結し、MD5ハッシュ値を求める
- リクエストのHTTPヘッダのresponseに③を入れて、再送信する
利点
- パスワードに関するセキュリティリスクを低減
- パスワードを盗まれる危険性がない
- パスワードそのものを預けなくてもよい、パスワードのハッシュ値を保管すだけ
欠点
- パスワード以外のセキュリティリスクは回避できない
- パスワードのみを暗号化
- メッセージ自体は平文でネットワーク上に流れる
- クライアント側の負担が大きい
- 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
(nonceを取得するため)
普及していない理由
- クライアント側の負担が大きい
- ApacheなどのWEBサーバーではDigest認証がオプション扱い
- ホスティングサービスではサポートされていない可能性が高い
- 自前で用意する場合もセキュリティ上の問題でApacheがヘッダーを渡してくれないため、Digest認証を利用できない
WSSE
- HTTP1.1の標準外の認証方式
- AtomPubやWEBAPIの認証で利用
- Basic認証やDigest認証が利用できない場合にパスワードをネットワーク上に 流さずに認証するために誕生
- WS-SecurityのUsernameTokenがベース
方式
クライアント側
- クライアントが認証情報なしでリクエスト
- クライアントがリクエストを再送信
- AuthorizationヘッダにWSSE、profileにサーバから受け取ったUsernameTokenを設定
- X-WSSEにパスワードダイジェスト、nonce、日時情報を設定
サーバー側
- サーバーが401 Unauthorizedを返却
- WWW-Authenticateにprofileを設定(UsernameToken)
- サーバーがクライアントのパスワードダイジェストと比較して認証
サーバー側でパスワードを保存する必要がある
- パスワードがネットワーク上に流れることはない
- Basic認証とDigest認証の中間
キャッシュ
持続的接続
- HTTP1.1からの追加機能
問題
- リクエストレスポンスのたびにTCPコネクションの確立、切断を繰り返していた
→処理が重くなっていた。画像や外部ファイルが多いWebページだととくに
解決
- 都度接続、切断を繰り返すのではなく、接続し続ける手法が開発
- HTTP1.0ではオプション(keep-alive)
- HTTP1.1ではデフォルト
- パイプライン化
- クライアントはサーバからのレスポンスを待たずに同じサーバーにリクエストを送信可能
- コネクションを切断したい場合、(Connection:close)を指定
その他のHTTPヘッダ
- Content-Disposition
- サーバがクライアントにファイル名を提示
- 電子メール仕様から伝承
- 文字エンコーディングが必要
まとめ
- HTTPヘッダはメソッドやステータスコードと組み合わせて認証やキャッシュなどのHTTPの重要な機能を実装
- 電子メールや文字エンコーディングは深い歴史があり、バッドノウハウを引き継いでいる。
- HTTPヘッダをうまく利用するためにサーバやブラウザだけでなく、電子メールや文字エンコーディングの歴史も調査する必要がある
【WEBを支える技術】を読む理由 - WEB道楽
【WEBを支える技術】REST編 - WEB道楽
【WEBを支える技術】URI仕様編 - WEB道楽
【WEBを支える技術】URI設計編~良いURI設計とは~ - WEB道楽
【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - WEB道楽
【WEBを支える技術】HTTPメソッド編~名は体を表す~ - WEB道楽
【WEBを支える技術】HTTPステータス編~名は体を表す~ - WEB道楽