三章 HTTP

Tweet

HTTPヘッダ

HTTPヘッダの重要性

ヘッダは、メッセージのボディに対する付加的な情報。メタデータを表現する。
クライアントやサーバーは、ヘッダを見てメッセージに対する挙動を決定する。
クライアントとサーバーの通信回数と量を減らす「キャッシュ」などの機能はヘッダで実現する。
※ 正確に書くと、メソッドやステータスコードを組み合わせる必要がある。

日時

日時を持つヘッダ。

利用するメッセージ	ヘッダ	意味
リクエストとレスポンス	Date	メッセージを生成した日時
リクエスト	if-Modified-Since	条件付きGETでリソースの更新日時を指定する
リクエスト	if-Unmodified-Since	条件付きPUTや条件付きDELETEでリソースの更新日時を指定する
レスポンス	Expires	レスポンスをキャッシュできる期限
レスポンス	Last-Modified	リソースを最後に更新した日時
レスポンス	Retry-After	再度リクエストを送信可能になる日時の目安

MIMEメディアタイプ

メッセージでやり取りするリソースの表現種類を指定するのが、MIMEメディアタイプ。
(Mulitpurpose Internet Mail Extensions)
電子メールからもらった仕様になる。
オリジナルのMIMEでは、複数のメールヘッダを定義する仕様。
HTTPでは、Content-Typeヘッダ等、いくつか利用する。

※MIMEメディアタイプ=>メディアタイプと呼ぶ

Content-Type

メディアタイプを指定する。

Content-Type：application/xhtml+xml;charset=utf-8

この場合、application/xhtml+xmlがメディアタイプ。
具体的には、下のようになる。

• application：タイプ
• xhtml+xml：サブタイプ

タイプ

タイプはすでに決まっている。
具体的には、下の通り。

タイプ	意味	例
text	人が呼んで直接理解できるテキスト	text/plain
image	画像データ	image/jpeg+png
audio	音声データ	audio/mpeg
video	映像データ	video/mp4
application	そのほかのデータ	application/pdf
multipart	複数のデータからなる複合データ	multipart/related
message	電子メールメッセージ	message/rfc822
model	複数次元で構成するモデルデータ	model/vrml
example	例示用	example/test

サブタイプ

「タイプ/サブタイプ」で指定可能。
また、接頭辞を「x-」にすることで、独自のサブタイプを作成することが可能。

サブタイプ	意味
text/plain	プレーンのテキスト
text/CSV	CSVのテキスト

以下略

Charset

文字エンコーディングを指定するパラメータ。
例では、「charset=utf-8」として表記している。実は省略可能。
HTTPのtextタイプは、デフォルト設定で「ISO 8859-1」になっている。
文字化けを防ぐために、「charset、urf-8」は必要になる

HTTP/1.1 200 OK
Content-Type：application/xhtml+xml;charset=utf-8

<?xml vertsion="1.1" encording="utf-8"?>
<test>文字化け怖い</test>

この時重要なのは、ヘッダの部分で「charset=utf-8」を宣言していること。

言語タグ

Content-Language:ja-JP

この表記で自然言語設定ができる

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

クライアントと交渉してメディアタイプやエンコーディングを決めることができる。

Accept

処理できるメディアタイプをサーバーに伝える

Accept-Charset

処理できる文字エンコーディングを伝える

Accept-Language

処理できる言語を伝える

Content-Length

メッセージが、ボディを持ている場合、基本的にはContent-Lengthヘッダを利用して、そのサイズを10進数のバイト数でしめす。
この時、静的なファイル(文字ファイルだけ等)ならば、サイズを表示するのは容易。

Content-Length:5538

チャンク転送

動的に画像を生成するサービス等の場合、ファイルサイズが決まるまでレスポンスを返せないので、応答性が低下する。
この時に使用するのが、Transfer-Encordingヘッダ
最終的なサイズがわからないボディを、少しずつ転送できるようになる。
各チャンクの先頭には、16進数が入る。

Transfer-Encording:chunked

10 
The brown fox ju

10
mps quickly over

e
the lazy dog

認証

現在主流のHTTP認証方式は、2種類。

1. Basic認証
2. Digest認証

また、WSSEというHTTPの拡張仕様を利用する場合もある。
あるリソースにアクセス制御がかかっている場合、ステータスコード401とWWW-Authenticateヘッダを利用して、認証情報を通知できる

リクエスト

DELETE/test HTTP/1.1
Host:example.jp

レスポンス

HTTP/1.1 401 Unauthhorized
www-authenticate:Basic realm="Example.jp"

上の例では、Basic認証を採用採用していることがわかる。
「realm」は、サーバー上でリソースが属しているURI空間の名前。
※ 401は認証が失敗したことを示すエラー。パスワードが違う場合にも変える。
※ URI空間とは「○○/××」のパス下にあるURIすべてのこと。

Basic認証

Basic認証は、ユーザ名とパスワードによる認証方式。

リクエスト

DELETE/test HTTP/1.1
Host:example.jp,
Authorization:Basic dxnlsjpAefgTEgefd == 

ユーザ名とパスワードを「:」で連結する。「ユーザ名」:「パスワード」。
Base64エンコーディングは、でコードが簡単。上が暗号のようになっているが、簡単に文字列に戻せる。
つまり、「ユーザ名」と「パスワード」が平文で送られている。
※ セキュリティを強化する場合は、SSLやTLSを使って暗号化する必要がある。

Digest認証

Digest認証は、Basic認証よりもセキュア(安全)。
Digest認証は、メッセージのダイジェストの略。ハッシュ関数を適用したハッシュ値のこと。

チャレンジ

Digest認証でも、クライアントはまず認証情報なしでリクエストを送信する。認証が失敗し、「401 Unauthorized」が返ってくる。

<h5>リクエスト</h5>

DELETE/test HTTP/1.1
Host:example.jp

<h5>レスポンス</h5>

HTTP1.1 401 Unauthorized
WWW-Authenticate:Digest realm="Example.jp",
nonce = "19Pnjedtakmgoene",qop="auth",
opaque="92eaogehepeiogerDj"

Basic認証に比べて、WWW-Authenticateのヘッダの値が複雑になる
このヘッダの値を「チャレンジ」と呼ぶ。
クライアントは、チャレンジを使用して、次のリクエスト組み立てる。

• nonce：一度だけ使われる数字。リクエストごとに変化する
• qop：品質の保証。クライアントが送信するダイジェストの作成法に影響を与える。「auth」か「auth-init」を指定する

No	名称	説明
1	nonce	一度だけ使われる数字。リクエストごとに変化する
2	qop	品質の保証。クライアントが送信するダイジェストの作成法に影響を与える。「auth」か「auth-init」を指定する。

• auth：メソッドとURIからダイジェストを利用して作成する
• auth-init：メソッドとURIとメッセージボディを利用して作成する

<h5>ダイジェストの生成と送信</h5>

サーバーから認証に必要な情報を得たクライアントは、自分のユーザ名とパスワードを使って、ダイジェストを生成する。
ダイジェストの生成は、下の3段階に分かれる。

1. ユーザ名,realm,パスワードを「:」で連結。MD5ハッシュ値を求める
2. メソッドとURIのパスを「:」で連結。MD5ハッシュ値を求める
3. 1の値,サーバーから得たnonce,クライアントがnonceを送った回数,クライアントが生成したnonce,qopの値,2の値を「:」で連結。MD5ハッシュ値を求める。

※ 認証が完了すると、200 OKが返る

Digest認証の利点/欠点

<h5>利点</h5>

• パスワードが盗まれる危険性はない
• パスワードをサーバーに預けなくてよい(セキュア)

<h5>欠点</h5>

• メッセージ自体は、平文でネットワークを流れる(暗号化したい場合はHTTPS)
• サーバーからのnonceが毎回変わるので、毎回認証が必要

WSSE認証

HTTP1.1標準外の認証方式
オプション扱いになることが多い。パスワードをネットワーク上に流さない＋Digest認証が使えないケースから開発された。

OpenIDとOAuth

シングルサインオン

ここまで説明した方式では、Webサービスにアカウントを作成し、ログインすることを繰り返す必要がある。
よって、アカウントの数が膨大になるという欠点がある。
また、Webサービス同士でユーザが持っているデータをやり取りしたい要望が出てきた。
これらの課題を解決するのが、「OpenID」「OAuth」

OpenID

シンプルなシングルサインオン

OpenIDを用いると、ユーザは「IdP」に持っている自分のアカウントで「SP」にログインできる。

• Idp：Yahoo等のWebサービスのアカウントをほかのサービスにも提供する
• SP：Idpのアカウントを利用して、独自のWebサービスを提供する

OAuth

Webサービス間での認可の移譲

OAuthは、Webサービス同士でデータをやり取りする仕組み。
SPから、Consumerにデータを渡すことを同意することで、お互いにデータのやり取りをする。
この機能を、「認可情報を移譲する機能」と呼ぶ。

• SP：(例)写真の保存
• Consumer：(例)保存している写真の印刷