Hatena::ブログ(Diary)

あすのかぜ Twitter

2016-05-25

Mixed ContentのブロックされたURIをレポートさせる仕様追加

Mixed Content

Mixed Contentと言う仕様により、httpsで提供しているページの中でhttpで提供するリソース(script等)があるとそのリソースはブロックされます。


このMixed Contentには、Content Security Policyのblock-all-mixed-contentディレクティブも定義されています


Content-Security-Policy: block-all-mixed-content

このディレクティブは、scriptなどのBlockable Contentだけでなく、画像や動画といったOptionally-blockable Contentもブロックするようにするためのディレクティブです。


このblock-all-mixed-contentの仕様にレポート機能が追加された模様(間違い等あればご指摘下さい



violation reports

このcspのblock-all-mixed-contentディレクティブは今までレポート機能はありませんでしたが、先日レポート機能が追加されました。(commit)


もともとCSPにはレポート機能があり、違反した時に設定したreport-uriへjsonで違反情報が送信されます。block-all-mixed-contentでも、このCSPの仕様に則る形になりました。

つまり、リクエストされたURLがviolation’s resourceにセットされ、blocked-uriとしてレポートされるようになります。


Chromeでは、このレポート機能は既に開発中です(URL)。もちろん、実際にブロックは行なわずレポートだけする Content-Security-Policy-Report-Onlyもサポートされていそうです。

2016-05-17

Cache-Control: immutableについて

こちらの記事で紹介されている、"Cache-Control: immutable"について試してみる

https://bitsup.blogspot.jp/2016/05/cache-control-immutable.html?m=1


Cache-Control: immutable

基本的にブラウザは、画像などのリソースキャッシュします。

ページ遷移などで移動した際、再度その画像を取得する場合はcache-controlの条件内であればキャッシュを利用します。


しかし、リロードボタンを押すとConditional GETと呼ばれるif-modified-sinceヘッダなどが付いたリクエストを送信し、リソースが更新されていないか確認しに行きます。304 Not Modifiedが帰ってきた場合は無事キャッシュを使用することが出来ます。(スーパーリロードの場合は通常のHTTPリクエストになります)


Cache-Control: immutable は、このリロード時もcache-controlの条件内であればサーバに確認せずにキャッシュを利用できるようにする仕組みのようです。RFC7234のCache Control Extensionsではcache-controlヘッダの拡張が許可されており、対応してないクライアントは無視するように指定されています。


試す

Firefoxのソースコードを見るとimmutableに関するコードが入ってそうなので、試してみた。


画像を2つ用意し、片方にはimmutableをつけてリロードボタンを押す

( https://asnokaze.com/demo/cache-control-immutable.html )


f:id:ASnoKaze:20160517022304p:image

こんな感じで、片方の画像は304だが、もう片方はキャッシュから読み込んでるのが分かる。


余談

chromiumのnet-devグループでも「Cache-Control: immutable」の話題が出ている。

https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!topic/net-dev/rGNMUJFQ0Q4


その中で、chromiumの様々な種類のリロードに関してまとまった資料が大変興味深かった

https://docs.google.com/document/d/1vwx8WiUASKyC2I-j2smNhaJaQQhcWREh7PC3HiIAQCo/edit

2016-05-14

CloudFlareのNGINX HTTP/2 + SPDY両対応するパッチを試す

CloudFlareから、「Open sourcing our NGINX HTTP/2 + SPDY code」という記事にて、NginxをHTTP2とSPDYに両方に対応するパッチが公開されました。


NginxはHTTP2対応に伴い、SPDYのコードは削除されました。しかし、一部古いブラウザはSPDYまでしか対応してないものもあります。そういったブラウザのためにSPDYをサポートするのは少なからず効果があるのだと思われます。


設定の仕方や、ビルドに必要な物はSPDY対応していた頃と同等のようなのでパッチさえ当てれば特に特殊なことはなさそうでした。


ビルドする

Nginx 1.9.7 とパッチをダウンロードしてビルドする。

wget http://nginx.org/download/nginx-1.9.7.tar.gz
tar zxvf ./nginx-1.9.7.tar.gz
cd ./nginx-1.9.7/

wget https://raw.githubusercontent.com/cloudflare/sslconfig/master/patches/nginx__http2_spdy.patch
patch -p1 < ../nginx__http2_spdy.patch


#必要があれば --with-opensslでopenssl-1.0.2 を追加する
./configure --with-http_spdy_module --with-http_v2_module --with-http_ssl_module
make

conf

server {
    listen       443 spdy http2 ssl;
    server_name  localhost;

    ssl_certificate      server.crt;
    ssl_certificate_key  server.key;
...

試す

http2

vagrant@vagrant:~$ nghttp https://localhost -nv
[ERROR] Could not connect to the address ::1
Trying next address 127.0.0.1
[  0.005] Connected
[  0.012][NPN] server offers:
          * h2
          * spdy/3.1
          * http/1.1
The negotiated protocol: h2

...

spdy

vagrant@vagrant:~/spdylay$ ./src/spdycat https://localhost -nv
[  0.009] NPN select next protocol: the remote server offers:
          * h2
          * spdy/3.1
          * http/1.1
          NPN selected the protocol: spdy/3.1
[  0.022] Handshake complete
[  0.022] recv SETTINGS frame <version=3, flags=1, length=20>
          (niv=2)
          [4(0):100]
          [7(0):2147483647]

...