https://chromium.googlesource.com/chromium/src.git/+/52b672b2462d6a3751a13187a1003e6fffdfbfbd

手元で確認した限りだと、バージョン 51.0.2704.63 (64-bit) で accept-encoding:gzip, deflate, sdch, br が送信されるようになっていました。

フラグとしてはバージョン49で実装されていたみたいですが、51 (2016-05-25)でようやくデフォルトでも有効になりました。リリースノートには書いてませんが、「log」をたどると上記コミットで有効になったことがわかります。

他のブラウザだと Firefox は 44 (2016-01-26)から有効になっています。

なお、Chrome でも Firefox でも brotli 対応は HTTPS 限定です。

1. トップ
2. tech
3. Chrome の brotli 圧縮アルゴリズム対応がデフォルトで有効に

h2o は compress: ON にすると、レスポンスに accept-encoding に応じたオンザフライな圧縮が有効になります。ただしデフォルト状態ではcontent-type が text/ から始まる場合と +xml で終わる場合に限られているようです。

この条件に一致しない application/json などに対しても圧縮をかけたい場合、file.mime.settypes で設定すれば良いようです。すなわち

    file.mime.settypes:
      "application/json":
        extensions: [".json"]
        is_compressible: yes 
        priority: normal

このようにすれば application/json でも自動的に圧縮してくれます。

これは file. で始まるディレクティブですが、バックエンドサーバから送るレスポンスに対しても(リバースプロキシとしても)これで圧縮がかかるようになります。

1. トップ
2. tech
3. h2o で特定のファイルがオンザフライ圧縮されないとき

http://www.sqlite.org/withoutrowid.html WITHOUT ROWID 最適化について

SQLite は常に暗黙的な rowid カラムを持っていることになっている。これはカラムとして明示することもできるし、interger primary key として定義されたフィールドは暗黙的な rowid の代わりにすることができる。SQLite ではこの rowid が基本のプライマリキーになっている。

適当な数値をプライマリキーにしたい場合はこれで全く問題ないが、複合キーだったり文字列をプライマリキーにしたい場合、その表面上のプライマリキーとは別に rowid カラムができる。このケースでは表面上のプライマリキーを使って SELECT しようとすると、表面上のプライマリキーのインデックスを探したうえで、さらに rowid のインデックスを探すことになる。つまり、このケースのプライマリキーとは単に UNIQUE なインデックスでしかない。

そこそこ最近(3.8.2・2013年)からは WITHOUT ROWID をテーブル定義時に指定することで、暗黙的な rowid 生成を抑制して、プライマリキー指定した定義を「真のプライマリキー」とすることができる。

これによって

• インデックスを辿る回数が減るのでパフォーマンスがあがる
• 表面上のプライマリキー→rowid のインデックスがなくなるのでDBサイズが減る
• インデックスが減るので挿入時の負荷が減る

と良いことがある。一方デメリットで気になるのは

• 古い SQLite (3.8.2 より前) で該当DBを読もうとすると malformed database schema で怒られて読めない
• sqlite3_last_insert_rowid() が使えない
• インクリメンタルblob I/Oが使えない (大きなカラムを少しずつ読める低レベルな仕組み)

1. トップ
2. tech
3. SQLite で「PRIMARY KEY」を《真のプライマリキー》とするには