それでは毛玉諸君、これにて失敬

日々の精進を備忘録的に綴ります。

Webを支える技術 ~P151まで

好きな言葉は「果報は寝て待て」、ko_ya346です。
やりますよーー!

HTTPメッセージ

GET /test HTTP/1.1
Host: example.jp
  • 1行目
    • メソッド、リクエスURIプロトコルバージョン
    • URIフラグメントを除くパス以降の文字列が入る
    • 以下のように絶対URIでもリクエスト可能
GET http://example.jp/test HTTP/1.1
  • 2行目
    • ヘッダ(メッセージのメタデータ
    • 「名前:値」の構成
  • 以降
    • bodyが続くことも

HTTPメソッド

CRUD(GET, POST, PUT, DELETE)

  • GET
    • 指定したURIの情報を取得
  • POST
    • 子リソースの作成
      • レスポンス 201(新規リソース生成)
    • リソースへのデータの追加
    • 長いURIに対してGET
    • クライアントはリソースのURIを指定できない
      • サーバ側が決定する
      • twitter投稿とか
  • PUT
    • リソースの更新
    • リソースの作成
    • リソースのURIはクライアントが決定する

メソッドの誤用

  • GETが安全でなくなる例
GET /resources/1/delete HTTP/1.1
Host: example.jp
  • POSTを誤用した例
    • ほかのメソッドでできることにPOSTを使用
    • XML-RPCSOAP
      • どちらもRPCを実現するためのプロトコルだが、すべての関数呼び出しをPOSTで実現するよう設計されている
  • POSTがべき等でなくなる
# request
GET /tomato HTTP/1.1
Host: example.jp

# response
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8

100

# request
PUT /tomato HTTP/1.1
Host: example.jp
Content-Type: text/plain; charset=utf-8

+50

# response
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8

150

べき等性(何度やっても同じ結果になる)

  • GET, HEADはべき等かつ安全
  • PUT, DELETEはべき等

ステータスコード

  • 1xx: 処理中
  • 2xx: 成功
    • 200: リクエスト成功
    • 201: リソースの作成成功
  • 3xx: リダイレクト
    • 301: リソースの恒久的な移動
    • 303: 別URI参照
  • 4xx: ライアントエラー
    • 400: リクエスト間違い
    • 401: アクセス権不正
    • 404: リソース不在
  • 5xx: サーバエラー
    • 500: サーバ内部エラー
    • 503: サービス停止

HTTPヘッダ

HTTPヘッダの重要性

  • メタデータを表現
    • クライアントやサーバはヘッダを見て挙動を決定
  • リソースへのアクセス権を設定する認証やキャッシュなどHTTPの機能を実現

MIMEメディアタイプ

  • Multipurpose Internet Mail Extensions
  • メッセージでやり取りするリソースの表現の種類を指定

Content-Type

  • メッセージのボディの内容がどんな種類なのか示す
# XHTML
Content-Type: application/xhtml+xml; charset=utf-8
  • application/xhtml+xml がメディアタイプ
    • /の左側がタイプ
    • /の右側はサブタイプ

charset

  • 文字エンコーディングを指定
  • Content-Typeで指定したtypeがtextのとき要注意
    • デフォルト文字エンコーディングはISO 8859-1なので文字化けしがち
    • XMLのように文書本体で文字エンコーディングを宣言出来ても、textタイプの場合はContent-Typeヘッダのcharsetパラメータを優先しなければならない
    • ↓の例はXMLで宣言しているUTF-8は無視される
HTTP/1.1 200 OK
Content-Type: text/xml

<?xml version="1.0" encoding="utf-8"?>
<test>日本語文字列</test>

Content-Language

Content-Language: ja-JP

Content Negotiation

  • メディアタイプや文字エンコーディング、言語タグをサーバが一方的に決めるのではなく、クライアントと交渉して決めるための手法

Accept

  • クライアントが自分の処理できるメディアタイプをサーバに伝える
  • 複数のメディアタイプとそれらの優先度を付ける
Accept: text/html.application.xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  • サーバが対応してなかったら406を返す

Accept-Charset

Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7

Accept-Language

  • クライアントが自分の処理できる言語をサーバに伝える

Content-Lengthとチャンク転送

  • Content-Length
    • ボディの長さを指定
Content-length: 5538
  • チャンク転送
    • ボディを分割して転送
Transfer-Encoding: chunked

認証

  • あるリソースにアクセス制御がかかっている場合、以下のようにリソースへのアクセスに必要な認証情報を通知する
# request
DELETE /test HTTP/1.1
Host: example.jp

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

Basic認証

  • ユーザ名とパスワード
  • Authorizationヘッダに入れてリクエスト毎に送信します
    • 認証方式に続けてユーザ名とパスワードを:で連結しBase64エンコードした文字列
  • Base64エンコーディングは簡単にデコードできるのが欠点
DELETE /test HTTP/1.1
Host: example.jp
Authorization: Basic aa......

Digest認証

  • 認証なしでリクエストすると以下が返ってくる
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="Example.jp", nonce="{ランダムな文字列}", qop="auth", opaque="{ランダムな文字列}"
  • nonce
    • number used once
  • qop
    • quality of protection
    • クライアントが送信するダイジェストの作成方法に影響を与える
  • opaque

    • クライアントからは推測できない文字列
  • ダイジェストを生成してリクエストする(生成手順は省略)

WSSE認証

  • パスワードそのものをネットワーク上に流さなくて良く、Digest認証ほど面倒ではない
  • サーバ側に生のパスワードを保存する必要がある

キャッシュ

  • サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法
  • キャッシュが有効な間はクライアントが再度そのリソースにアクセスしようとしたときに再利用する

次はHTML!