Hatena::ブログ(Diary)

あすのかぜ Twitter

2016-08-21

Site-Wide HTTP Headers とは

Mark Nottingham氏から、HTTPレスポンスヘッダをサイト全体で使いまわせるようにする 「Site-Wide HTTP Headers」 という仕様が提案されています。

https://tools.ietf.org/html/draft-nottingham-site-wide-headers-00


例えば、Public-Key-PinsやStrict-Transport-Securityというものはオリジン全体に適応されるヘッダですし、Content-Security-Policyも殆どの同じように使用されます。HTTP/2になりHPACKでヘッダは圧縮されるものの、デフォルトで4KでありContent-Security-Policyがそのうちの殆どを使用してしまってるケースも観測されています(3KのCSPヘッダなどもあるようです)。


そこで、HPACKのサイズも抑えるために、より少ないヘッダでサイト全体に適応されるヘッダを表現できるようにするのが、Site-Wide HTTP Headersです。


  • 1. ユーザエージェントはまず、site-headersを取得します
  • 2. 次回からユーザエージェントはHTTPリクエストを送信する際、site-headersを持ってることを通知します
  • 3. サーバはsite-headersを指し示して、site-headersのヘッダが付加されていることを示します
1. site-headersリソースの取得

サーバはRFC5785で定義される、URIでsite-headersリソースを提供します。このリソースはユーザエージェントによってGETで取得するか、サーバからServerPushで送信されます。

このHTTPレスポンスでは、Content-Typeに"text/site-headers"がセットされます。さらに、ETagが付加されて無ければなりません。

# a以下がサイト全体で使用するヘッダセットです。

HTTP/1.1 200 OK
Content-Type: text/site-headers
Cache-Control: max-age=3600
ETag: "abc123"
Content-Length: 1234

# a
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Server: Apache/2.4.7 (Ubuntu)
Public-Key-Pins: max-age=604800; 
  pin-sha256="ZitlqPmA9wodcxkwOW/c7ehlNFk8qJ9FsocodG6GzdjNM=";
  pin-sha256="XRXP987nz4rd1/gS2fJSNVfyrZbqa00T7PeRXUPd15w="; 
  report-uri="/lib/key-pin.cgi"


2. HTTPリクエスト

ユーザエージェントが改めてfoo.jpg等の別のリソースを取得するためにHTTPリクエストを送信する場合、最新のsite-headersリソースを持ってる事を示すために、SMヘッダに取得した時のETatの値を付加します。

GET /images/foo.jpg HTTP/1.1
Host: www.example.com
SM: "abc123"


3. HTTPレスポンス

サーバはHSヘッダで、site-headersの#aがこのレスポンスヘッダには付け加えて解釈するようにユーザエージェントに指示します。

HTTP/1.1 200 OK
Content-Type: image/jpeg
Vary: SM, Accept-Encoding
Cache-Control: max-age=3600
HS: "a"
Transfer-Encoding: chunked


つまり、上記のHTTPレスポンスヘッダは下記のように解釈されます

HTTP/1.1 200 OK
Content-Type: image/jpeg
Vary: SM, Accept-Encoding
Cache-Control: max-age=3600
Connection: close
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Server: Apache/2.4.7 (Ubuntu)
Public-Key-Pins: max-age=604800; 
  pin-sha256="ZitlqPmA9wodcxkwOW/c7ehlNFk8qJ9FsocodG6GzdjNM=";
  pin-sha256="XRXP987nz4rd1/gS2fJSNVfyrZbqa00T7PeRXUPd15w="; 
  report-uri="/lib/key-pin.cgi"

2016-07-27

ポリシーをオリジン全体に適応する Origin Policy

WICGで議論されている「Set origin-wide policies via a manifest」の仕様がGoogleのMike West氏から提案されています。この「Origin Policy」と言う仕様は、氏のGithubリポジトリから確認できます。


これは、Content-Security-PolicyやReferrer-Policyといったレスポンスヘッダでリソースごとに毎回指定していたものを、Origin Policy Manifestとしてオリジンに対して指定できるようにするものです。


クライアントは、このマニフェストに書かれているヘッダがレスポンスヘッダに付いていると仮定して処理を行います。


サーバはまず、レスポンスヘッダのOrigin-Policyヘッダでマニフェストファイルの場所を指示します。

HTTP/1.1 200 OK
Content-Encoding: gzip
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
...
Origin-Policy: "policy-1"

Origin-Policyを受信したクライアントは、そのマニフェストファイルを取りに行きます。Origin Policyのマニフェストファイルは.well-known/origin-policy/に置くことになっており、今回は「https://example.com/.well-known/origin-policy/policy-1」から取得します。

このマニフェストファイルもHTTP/2のPushを使用することで遅延を抑えられる旨仕様に書かれています。マニフェストファイルは以下の様になっています

{
  "headers": {
    "fallback": [
      {
        "name": "Content-Security-Policy",
        "value": "script-src 'self' https://cdn.example.com"
      },
      {
        "name": "Referrer-Policy",
        "value": "origin-when-cross-origin"
      }
    ],
    "baseline": [
      {
        "name": "Content-Security-Policy",
        "value": "object-src 'none'; frame-ancestors 'none'"
      },
      {
        "name": "Strict-Transport-Security",
        "value": "max-age=10886400; includeSubDomains; preload"
      },
      {
        "name": "X-Content-Type-Options",
        "value": "nosniff"
      }
    ]
  },
  "cors-preflight": { /* TODO(mkwst): Syntax? */ },
}

baselineは今後の全てのレスポンスヘッダに追加して解釈されるもので、fallbackは今後のレスポンスヘッダに該当のヘッダがなかった場合に追加して解釈されるヘッダが指定されます。

cors-preflightは、サーバがCORSの通信を解釈できることを示しています。クライアントは幾つかのCORS-preflightリクエストが成功することを前提に出来るようです。


クライアントは以降より、リクエストヘッダに適応しているマニフェストファイル名をOrigin-Policyヘッダに付加します。(適応しているOrigin Policyが無ければ、「Origin-Policy: 0」)

2016-07-25

QUICの仕様を翻訳していく

QUIC in ietf96

Google の試験的トランスポート、QUIC のアップデート」などでも紹介されている、Googleが提案・実装してるQUIC。


すでに関連するドキュメントはChromium Projects配下のページで公開されていますが、先日IETFにQUICの仕様が提出されています。


さらに先週ドイツで行なわれたIETF96の中でQUICに関する議論が行なわれ、IETFとしてQUICの標準化を進める事が決まりました。セッションの発表ではQUICのプロトコルのオーバービュー、Googleでのデプロイ状況及び統計情報、Akamaiからの発表、TLS1.3の使用に関する発表が行われましたその時の資料は、既にアップロードされています。

仕様

さて、既にIETFにはQUICに関する仕様が4つ提出されています。

Coreになる仕様を中心に、3つの仕様が付随しQUICというプロトコルを作り上げている。仕様としてはversion 00でありTODOや誤字などがある。また、TLSの仕様に関してはTLS1.3側の変更を取り込んだものが著者のgithubに上がっているものの、TLS1.3もまだ変更があるため今後も変更されるだろう。

翻訳

翻訳という大それたものではないが、読んだ副産物として翻訳を公開してみようと思う。自分でもわかりにくい部分があると思ってるので、時間を見つけて直していきます。完璧な翻訳を与えるものではありませんが、より良いものになるように努めます。


今のところ、4つのうち2つだけ

https://github.com/flano-yuki/my-quic-spec-translation


残りの仕様も読んでますが、やはり難しい...