CORS に対応する nginx 設定

CORS (Cross-Origin Resource Sharing) について以前調べました。

ブラウザは、実際に GET や POST する前に、プリフライトリクエストというリクエストを発行します。通常これは OPTIONS メソッドです。で、このときのレスポンスヘッダをみて、ブラウザは呼び出す/呼び出さないを決定します。
http://torufurukawa.blogspot.jp/2012/05/http-access-control.html

これを実現するのに nginx (1.2.1) の設定で困ったのでメモしておきます。ちなみに、このウェブサイトは Basic 認証をかけます。

http {
     #...
     server {
          listen 8080;
          server_name localhost;
          location / {
               root html;
               index index.html index.htm;

               # GET, POST 用のヘッダ設定
               add_header Access-Control-Allow-Origin *;
               add_header Access-Control-Allow-Methods "POST, GET, OPTIONS";
               add_header Access-Control-Allow-Headers "Origin, Authorization, Accept";
               add_header Access-Control-Allow-Credentials true;
               # Basic 認証設定
               auth_basic "xaxtuxo";
               auth_basic_user_file  "/usr/local/etc/nginx/.htpasswd";

               # OPTIONS 用の設定。ヘッダの指定をここにも書かないといけない。
               if ($request_method = OPTIONS ) {
                    add_header Access-Control-Allow-Origin *;
                    add_header Access-Control-Allow-Methods "POST, GET, OPTIONS";
                    add_header Access-Control-Allow-Headers "Origin, Authorization, Accept";
                    add_header Access-Control-Allow-Credentials true;
                    add_header Content-Length 0;
                    add_header Content-Type text/plain;
                    return 200;
               }
          }
     }
}

OPTIONS メソッドの設定を書いていなくて、最初、動きませんでした。また、 if ブロックの中にも、add_header をいちいち書く必要があります。

参考

https://gist.github.com/1064640

https://gist.github.com/1323477

システム発注側にとって要件は自明ではない

ズボンの股のあたりに穴があいて久しいので、服を買おうと街に繰り出しました。が、もうどうしていいか分からない。どんな色がいいか、どんなスタイルがいいかとか、全くわからない。今年の新色とか、デザインとか言われても、判断のしようがないんですよね。うっかり高そうな店に入ると、すぐに店員が話しかけてきて、要らないものを紹介してきますし。

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。（ジョエル・スポルスキー「ジョエル・オン・ソフトウェア」）

「何が欲しいのかは分からないが、これではないことは分かる」みたいな言い回しをどこかで聞いたのですが、思い出せません。とにかく発注側が要件が分かっている、と思ってはいけません。おそらく分かっていません。開発者自信が自分で使うライブラリやフレームワークを作る、みたいな状況でないかぎり、おそらく分かっていない、という前提くらいがちょうどいいと思います。

もちろん受注側はプロなので、まともな会社なら、ちゃんと考えてやってくれるでしょう。きっと素晴らしい提案が出てくるはずです。それでも、なんというか、自分たちが最終的に何を依頼しているのか、っていうのは、把握しておきたいなあ、と思う次第です。

ぜんぜんまとまってないし、以前にも似たことを書いたのですが、買い物をしようとして痛感したもので、もういちど書いておくことにします。

運用の継続的改善

ウェブサービスをリリースしたら、当然その運用が必要です。しかし、これがよく分かっていません。だいたい当初の想定にはモレがあって、後で困ります。経験と知識と思考の不足がなせる技です。

だからと言ってほったらかすわけにいかないので、一時期、毎日朝の1時間は運用の改善に当てていました。Skype やメールを見る前に、なにか改善する。改善は、1時間でなんらかの形になることにしていました。ちょっとしたスクリプトを書くこともありましたし、ダッシュボードを作ったりもしました。運用に便利な機能を、組み込んだりもしました。

また、同じようなことを最近始めました。いまでも運用は苦手です。ですが、こうやって毎日ちょっとずつやっていくうちに、じわじわ改善されていくのは嬉しいものです。毎日1%ずつ効率化していくと、1ヶ月たてば20%の効率化になります。

自社サービスの場合には、そういう時間の使い方ができるので、最初は苦しいですが、地味に続けていくと、ある時「おー、楽になったなぁ」となります。

最初から全部できればいいんですが、残念ながらできていないので、銀の弾丸を探さずに、ちまちまやってます。