# if 是邪惡的
當在location區塊中使用 if 指令的時候會有一些問題, 在某些情況下它并不按照你的預期運行而是做一些完全不同的事情. 而在另一些情況下他甚至會出現段錯誤. 一般來說避免使用 if 指令是個好主意.
在location區塊里if指令下唯一100%安全的指令應該只有:
##### return …;
##### rewrite … last;
除此以外的指令都可能導致不可預期的行為, 包括詭異的發出段錯誤信號(SIGSEGV).
要著重注意的是if的行為不是反復無常的, 給出兩個條件完全一致的請求, Nginx并不會出現一個正常工作而一個請求失敗的隨機情況, 在明晰的測試和理解下 if 是完全可用的. 盡管如此, 在這里還是建議使用其他指令.
總有一些情況你無法避免去使用 if 指令, 比如你需要測試一個變量, 而它沒有相應的配置指令.
~~~
if ($request_method = POST) {
return 405;
}
if ($args ~ post=140){
rewrite ^ http://example.com/ permanent;
}
~~~
#### 如何替換掉if
使用 try_files 如果他適合你的需求. 在其他的情況下使用 “return …” 或者 “rewrite … last”. 還有一些情況可能要把 if 移動到 server 區塊下(只有當其他的rewrite模塊指令也允許放在的地方才是安全的).
如下可以安全地改變用于處理請求的 location.
~~~
location / {
error_page 418 = @other;
recursive_error_pages on;
if ($something) {
return 418;
}
# some configuration
...
}
location @other {
# some other configuration
...
}
~~~
在某些情況下使用嵌入腳本模塊(嵌入perl或者其他一些第三方模塊)處理這些腳本更佳.
例子
以下是一些例子用來解釋為什么if是邪惡的. 非專業人事指, 請勿模仿!
~~~
# 這里收集了一些出人意料的坑爹配置來展示 location 中的 if 指令是萬惡的
# 只有第二個 header 才會在響應中展示
# 這不是Bug, 只是他的處理流程如此
location /only-one-if {
set $true 1;
if ($true) {
add_header X-First 1;
}
if ($true) {
add_header X-Second 2;
}
return 204;
}
# 因為if, 請求會在未改變uri的情況下下發送到后臺的 '/'
location /proxy-pass-uri {
proxy_pass http://127.0.0.1:8080/;
set $true 1;
if ($true) {
# nothing
}
}
# 因為if, try_files 失效
location /if-try-files {
try_files /file @fallback;
set $true 1;
if ($true) {
# nothing
}
}
# nginx 將會發出段錯誤信號(SIGSEGV)
location /crash {
set $true 1;
if ($true) {
# fastcgi_pass here
fastcgi_pass 127.0.0.1:9000;
}
if ($true) {
# no handler here
}
}
# alias with captures isn't correcly inherited into implicit nested location created by if
# alias with captures 不能正確的繼承到由if創建的隱式嵌入的location
location ~* ^/if-and-alias/(?<file>.*) {
alias /tmp/$file;
set $true 1;
if ($true) {
# nothing
}
}
~~~
#### 為什么會這樣且到現在都沒修復這些問題?
if 指令是 rewrite 模塊中的一部分, 是實時生效的指令.另一方面來說, nginx 配置大體上是陳述式的.在某些時候用戶出于特殊是需求的嘗試, 會在if里寫入一些非rewrite指令, 這直接導致了我們現處的情況. 大多數情況下他可以工作, 但是…看看上面.看起來唯一正確的修復方式是完全禁用if中的非rewrite指令. 但是這將破壞很多現有可用的配置, 所以還沒有修復.
#### 如果你還是想知道該如何使用if
如果你看完了上面所有內容還是想使用 if:
請確認你確實理解了該怎么用它.一些比較基本的用法可以在[這里](http://agentzh.blogspot.jp/2011/03/how-nginx-location-if-works.html)找到.
##### 做適當的測試.
我已經警告過你了!
> 文章選自:[http://xwsoul.com/posts/761](http://xwsoul.com/posts/761)TODO:這個文章后面需要自己翻譯,可能有版權問題:[https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/](https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/)
- 序
- Lua 入門
- Lua簡介
- Lua環境搭建
- 基礎數據類型
- 表達式
- 控制結構
- if/else
- while
- repeat
- for
- break,return
- Lua函數
- 函數的定義
- 函數的參數
- 函數的返回值
- 函數回調
- 模塊
- String庫
- Table庫
- 日期時間函數
- 數學庫函數
- 文件操作
- 元表
- 面向對象編程
- FFI
- 下標從1開始
- 局部變量
- 判斷數組大小
- 非空判斷
- 正則表達式
- 不用標準庫
- 虛變量
- 函數在調用代碼前定義
- 抵制使用module()函數來定義Lua模塊
- 點號與冒號操作符的區別
- Nginx
- Nginx 新手起步
- location 匹配規則
- if 是邪惡的
- 靜態文件服務
- 日志服務
- 反向代理
- 負載均衡
- 陷阱和常見錯誤
- 環境搭建
- Windows平臺
- CentOS平臺
- Ubuntu平臺
- Mac OS X平臺
- Hello World
- 簡單API Server框架
- 獲取Nginx內置綁定變量
- LuaRestyRedisLibrary
- select+set_keepalive組合操作引起的數據讀寫錯誤
- redis接口的二次封裝(簡化建連、拆連等細節)
- redis接口的二次封裝(發布訂閱)
- pipeline壓縮請求數量
- script壓縮復雜請求
- LuaCjsonLibrary
- json解析的異常捕獲
- 稀疏數組
- 空table編碼為array還是object
- 跨平臺的庫選擇
- PostgresNginxModule
- 調用方式簡介
- 不支持事務
- 超時
- 健康監測
- SQL注入
- LuaNginxModule
- 執行階段概念
- 正確的記錄日志
- 熱裝載代碼
- 阻塞操作
- 緩存
- sleep
- 定時任務
- 禁止某些終端訪問
- 請求返回后繼續執行
- 調試
- 調用其他C函數動態庫
- 我的lua代碼需要調優么
- 變量的共享范圍
- 動態限速
- shared.dict 非隊列性質
- 如何添加自己的lua api
- 正確使用長鏈接
- 如何引用第三方resty庫
- 典型應用場景
- LuaRestyDNSLibrary
- 使用動態DNS來完成HTTP請求
- 緩存失效風暴
- 測試
- 單元測試
- API測試
- 性能測試
- 持續集成
- 灰度發布
- Web 服務
- API的設計
- 數據合法性檢測
- 協議無痛升級
- 代碼規范
- 連接池
- C10K編程
- TIME_WAIT問題
- 與Docker使用的網絡瓶頸
- 火焰圖
- 什么時候使用
- 顯示的是什么
- 如何安裝火焰圖生成工具
- 如何定位問題
- 開源文化對360企業安全的影響