Nginx の location ブロックのパターン化

簡単そうに見えたのだが思い通りにいかない.

優先順位というか, 処理順序というか. ここらの話.

location  = / {
  # matches the query / only.
  [ configuration A ] 
}
location  / {
  # matches any query, since all queries begin with /, but regular
  # expressions and any longer conventional blocks will be
  # matched first.
  [ configuration B ] 
}
location /documents/ {
  # matches any query beginning with /documents/ and continues searching,
  # so regular expressions will be checked. This will be matched only if
  # regular expressions don't find a match.
  [ configuration C ] 
}
location ^~ /images/ {
  # matches any query beginning with /images/ and halts searching,
  # so regular expressions will not be checked.
  [ configuration D ] 
}
location ~* \.(gif|jpg|jpeg)$ {
  # matches any request ending in gif, jpg, or jpeg. However, all
  # requests to the /images/ directory will be handled by
  # Configuration D.   
  [ configuration E ] 
}

Nginx location priority - Stack Overflow

なので公式 wiki/recipe を見ながら少し整理.

PHP FastCGI Example | NGINX

Codeigniter | NGINX

Drupal | NGINX

osCommerce | NGINX

WordPress | NGINX

公式にて書式はこう.

Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }

Module ngx_http_core_module

複数のlocationブロックがある場合, リクエストのURL内該当文字列に対して優先順位の順番にマッチを確認していき, 最初にマッチしたロケーション設定(処理)ひとつが反映される.

1.「=」完全一致
2.「^~」前方検索 (マッチ文字列の長い順)
3.「~」正規表現 (記述順)
4.「~*」正規表現 (記述順・大小文字を考慮しない)
5.「(なし)」前方検索 (マッチ文字列の長い順)

これに加えて, それぞれの設定(処理)自体の優先順位を考慮しておかないと, 「アクセス拒否したつもりが丸出し」や「PHPスクリプトのダウンロード公開」などとなってしまう.

1. 特殊ファイルのログ制御
2. ディレクトリ単位のアクセス拒否
3. ファイル単位のアクセス拒否
4. PHPファイルの実行 (PHP-FPM)
5. 静的ファイルのキャッシュ期限の設定
6. フロントコントローラへのリクエスト付け替え

これら2つの優先順位を考慮にいれながら書かれている公式wiki/recipeの設定は, ある程度おおまかにパターン化できる.

1.「=」特殊ファイルのログ制御
2. 「^~」ディレクトリ単位のアクセス拒否
3.「~」ファイル単位のアクセス拒否
4.「~」PHPファイルの設定・実行 (PHP-FPM)
5.「~*」静的ファイルのキャッシュ期限の設定
6.「なし」フロントコントローラへのリクエスト付け替え

頻出しそうなのを順序を守って箇条書きに.

# 1. specific files 
location = /favicon.ico {
  log_not_found off;
  access_log off;
}

location = /robots.txt {
  allow all;
  log_not_found off;
  access_log off;
}

# 2. deny directories
location ^~ /conf/ {
  return 403;
}

# 3. deny files
location ~ (^|/)\. {
  return 403;
}

location ~ \.(txt|log)$ {
  allow 192.168.0.0/16;
  deny all;
}

# 4. php scripts
location ~ [^/]\.php(/|$) {
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  if (!-f $document_root$fastcgi_script_name) {
    return 404;
  }
  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
}

# 5. static content files
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
  expires max;
}

# 6. others(internal rewrite)
location / {
   try_files $uri $uri/ index.php;
}

実際はこれらに加えてさらに, 内部/外部での リライト/リダイレクトなどを記述して location 設定を複数またいでいくことになると, 大量に記述された apache mod_rewrite 設定のように直感的に設定できなくなっていくので locationブロックに関してはテンプレ化しておくのがいいように思う.

そもそもは「if」や「locationを使った入れ子」で混乱したので.

nginxのlocation設定について、優先順位の基本と意外な罠

If Is Evil | NGINX

if ($request_uri = /) { 
  set $test  A; 
} 
  
if ($host ~* teambox.com) { 
  set $test  "${test}B"; 
} 
  
if ($http_cookie !~* "auth_token") { 
  set $test  "${test}C"; 
} 
    
if ($test = ABC) { 
  proxy_pass http://teambox-cms.heroku.com; 
  break; 
} 

nginx hack for multiple conditions

手をつける前に, ある程度の歴史や経緯を分かっておく必要があったかな.

Nginx Configuration Primer

まあいいか.

みんなも reload したらチェックしてみよう.

$ curl -L http://yourhost.com/ -o /dev/null \
     -w '%{http_code} %{content_type} %{size_download} %{url_effective}\n' \
     -s

200 text/html; charset=UTF-8 1334 http://yourhost.com/

Android 6.0 (marshmallow) に更新されない機種一覧が見たい

ドコモからアナウンスがありました.

ドコモからのお知らせ : Android(TM) 6.0へのバージョンアップ予定製品について | お知らせ | NTTドコモ

じゃあ, 更新予定のない機種はなんなのか.

もしかして, 今どきは「OSは更新されない」のがフツーの大多数派なのか.

などと思い, 直近2年間にドコモから発売された機種を表にしてみる.

Marshmallow_アップデート_-_Google_スプレッドシート

まあ, どちらともいえない感じ.

例外はあるが, なんとなくおおまかに見えてくるのは,

国内産(シャープ・富士通)は, 発売日から1年までが更新対象

海外産(サムスン・ソニーモバイル)は, 発売日から1年半までが更新対象

という雰囲気か.

Nexus系については, 「2年更新保証の月次更新付」とGoogleからアナウンスがでてるのだが.

Official Android Blog: An Update to Nexus Devices

ところで, 必死にバイトして親とケンカしてまで買ったわたしの「ディズニーモバイル」は, ずっと放置なのですかっ!! (怒)


Android 次期バージョン N は Oracle Java を使わないのか?

Diff_-_51b1b6997fd3f980076b8081f7f1165ccc2a4008^__-_platform_libcore_git_-_Git_at_Google

技術ネタ満載の YCombinator の運営する「Hacker News」で昨日から話題になっています.

Google confirms next Android version won’t use Oracle’s proprietary Java APIs | Hacker News

このへん素人目にも想像できるのは「著作権料を払いたくない」という理由.

So in order for Google to avoid paying that royalty going forward they need to move to OpenJDK quickly with their next release, with the belief that using Oracle's GPL JDK implementation also gives them a license to the API (which is somehow separately copyrightable? The Federal Circuit is a mess).

ここらの適用範囲などの法律の話は金額のわりに明快でなく庶民には分かりづらい.

実際, 開発中のソースコードではどのようになってきているのか.

Mysterious Android codebase commit | Hacker News

This diff is more explicit about what's going on:
https://android.googlesource.com/platform/libcore.git/+/aab9...
Change dependency from libart -> libopenjdkjvm.
There are also diffs adding lambda support, tweaking various classes for compatibility with applications that use reflection to access internal capabilities, and fixing lots OpenJDK compatibility bugs.

確かに, OpenJDK に移行してるようにも見えるが.

In the context of the recent juniper attack where some unauthorized code was committed without anybody noticing for years, it seems like it would be easy to hide a backdoor in such a big commit.
How do you go about checking the integrity of the code when you have so many files?
8902 files were changed, most added, and the commit says it's just importing openJDK files. Is there anybody checking that the source file imported haven't been modified to include some kind of backdoor?

はっきり「OpenJDKに移行を進めている」とは言い切れないのか.

WEBでは見づらいのでアプリで.

Hacker News Reader (翻訳) - Google Play の Android アプリ