Misunderstanding

前回のエントリーに、appfogにOctopressを設置する手順を書いた。ちょっと勘違いしていたところがあったので、補足。前回のエントリーについては修正してある。

I choose appfog for Octopress blogging. So how can I setup?

前回のエントリーで、appfogをOctopressのホスティング先に採用したと書いた。今回は実際の設置方法について。

Which is the best choice for the Japanese Octopress blogger

そういえば、Herokuにblogを置く事しか考えてなかったけど、他のPaaSとの比較を全然してなかった。その結果、日本でブログを作るには、実はappfogの方がいいんじゃないかという結論に至った。

gzip compression can reduce file size. But is it needed on every HTTP request?

前回の続きの話。

前回はhtml、css、jsファイルなどのテキストファイルに対して、gzip圧縮をかけるとネットワーク転送量を大幅に減らすことができ、heroku Ceder stack上で動かしているwebrickで、自動的に圧縮する方法について書いた。これはこれで便利だけれども、じゃあリクエスト毎に圧縮する必要はあるのかい？というと、実はなかったりする。

Octopressを使っている限りでは、生成されるhtmlファイルは静的なファイルなので、リクエスト毎に変わるわけではないし、publishする前にgzip圧縮できればベスト。gzip未対応のブラウザも今はほぼないだろうし。

Text file should be compressed

ブログ作りの話も。

PaaSって、gzipを勝手にかけてくれる気がしていたんだけど、どうやら思い込みだったようで、 2012年ぐらいから、herokuはnginxを経由せずに、直接webrickにリクエストが送られるように仕様変更されたらしい。

参考：Enable gzip compression for Rails 3.2 on heroku Cedar

All apps deployed to Heroku used to automatically compress pages they serve, by passing through Nginx’s gzip filter on the way out. But with their newest Cedar Stack, things have changed.

In Cedar, the HTTP requests terminates directly at your app server & no longer goes through a proxy server(Nginx), hence there can’t be automatic gzip compression.

herokuのドキュメントはHTTP Routing and the Routing Mesh#Gzipped responsesに書いてある。

Since requests to Cedar apps are made directly to the application server – not proxied through an HTTP server like nginx – any compression of responses must be done within your application.

なので、この記事に従って最初に試してみたのはこんなコード。