鍍金池/ 教程/ Java/ if 是邪惡的
定時任務
函數(shù)的參數(shù)
超時
一個 openresty 內(nèi)存“泄漏”問題
獲取 uri 參數(shù)
局部變量
sleep
灰度發(fā)布
TIME_WAIT
代碼覆蓋率
連接池
CentOS 平臺安裝
稀疏數(shù)組
如何只啟動一個 timer 工作?
變量的共享范圍
break,return 關(guān)鍵字
Nginx
SQL 注入
如何引用第三方 resty 庫
不同階段共享變量
獲取請求 body
動態(tài)生成的 lua-resty-redis 模塊方法
動態(tài)加載證書和 OCSP stapling
repeat 控制結(jié)構(gòu)
編碼為 array 還是 object
Nginx 靜態(tài)文件服務
執(zhí)行階段概念
Lua 函數(shù)
日期時間函數(shù)
健康監(jiān)測
與其他 location 配合
for 控制結(jié)構(gòu)
函數(shù)定義
HTTPS 時代
點號與冒號操作符的區(qū)別
String 庫
文件操作
OpenResty 最佳實踐
<code>ngx.shared.DICT</code> 非隊列性質(zhì)
使用動態(tài) DNS 來完成 HTTP 請求
代碼規(guī)范
什么是 JIT?
Windows 平臺安裝
正確的記錄日志
LuaNginxModule
不用標準庫
C10K 編程
控制結(jié)構(gòu)
請求中斷后的處理
Lua 環(huán)境搭建
Test::Nginx 能指定現(xiàn)成的 nginx.conf,而不是自動生成一個嗎
Lua 基礎(chǔ)數(shù)據(jù)類型
動態(tài)限速
PostgresNginxModule
簡單API Server框架
API 測試
location 匹配規(guī)則
虛變量
單元測試
防止 SQL 注入
select + set_keepalive 組合操作引起的數(shù)據(jù)讀寫錯誤
阻塞操作
全動態(tài)函數(shù)調(diào)用
Web 服務
典型應用場景
Nginx 新手起步
TLS session resumption
輸出響應體
調(diào)用代碼前先定義函數(shù)
module 是邪惡的
怎樣理解 cosocket
模塊
Socket 編程發(fā)展
如何對 Nginx Lua module 添加新 api
如何在后臺開啟輕量級線程完成定時任務?
如何定位問題
table 庫
json 解析的異常捕獲
如何安裝火焰圖生成工具
lua 中如何 continue
if 是邪惡的
為什么我們的域名不能被解析
抵制使用 module() 定義模塊
測試
body 在 location 中的傳遞
Lua 入門
子查詢
pipeline 壓縮請求數(shù)量
如何發(fā)起新 HTTP 請求
Lua 簡介
緩存失效風暴
Ubuntu 平臺安裝
日志輸出
緩存
Lua 面向?qū)ο缶幊?/span>
Nginx 陷阱和常見錯誤
Redis 接口的二次封裝(發(fā)布訂閱)
日志
訪問有授權(quán)驗證的 Redis
正則表達式
lock
熱裝載代碼
調(diào)用 FFI 出現(xiàn) &quot;table overflow&quot;
數(shù)據(jù)合法性檢測
禁止某些終端訪問
控制結(jié)構(gòu) if-else
調(diào)試
與 Docker 使用的網(wǎng)絡瓶頸
PostgresNginxModule 模塊的調(diào)用方式
用 do-end 整理你的代碼
FFI
什么時候使用
簡介
環(huán)境搭建
Mac OS X 平臺安裝
火焰圖
負載均衡
while 型控制結(jié)構(gòu)
如何定位 openresty 崩潰 bug
使用 Nginx 內(nèi)置綁定變量
判斷數(shù)組大小
請求返回后繼續(xù)執(zhí)行
Redis 接口的二次封裝
KeepAlive
反向代理
協(xié)議無痛升級
數(shù)學庫
元表
Vanilla 介紹
HelloWorld
LuaCjsonLibrary
持續(xù)集成
代碼靜態(tài)分析
網(wǎng)上有大量對 Lua 調(diào)優(yōu)的推薦,我們應該如何看待?
script 壓縮復雜請求
非空判斷
性能測試
函數(shù)返回值
API 的設計
kong 介紹
表達式
不支持事務
LuaRestyDNSLibrary 簡介

if 是邪惡的

當在 location 區(qū)塊中使用 if 指令的時候會有一些問題, 在某些情況下它并不按照你的預期運行而是做一些完全不同的事情。而在另一些情況下他甚至會出現(xiàn)段錯誤。一般來說避免使用 if 指令是個好主意。

在 location 區(qū)塊里 if 指令下唯一 100% 安全的指令應該只有:

return …; rewrite … last;

除此以外的指令都可能導致不可預期的行為, 包括詭異的發(fā)出段錯誤信號 (SIGSEGV)。

要著重注意的是 if 的行為不是反復無常的, 給出兩個條件完全一致的請求, Nginx 并不會出現(xiàn)一個正常工作而一個請求失敗的隨機情況, 在明晰的測試和理解下 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 區(qū)塊下(只有當其他的 rewrite 模塊指令也允許放在的地方才是安全的)。

如下可以安全地改變用于處理請求的 location。

location / {
    error_page 418 = @other;
    recursive_error_pages on;

    if ($something) {
        return 418;
    }

    # some configuration
    # ...
}

location @other {
    # some other configuration
    # ...
}

在某些情況下使用嵌入腳本模塊(嵌入 perl 或者其他一些第三方模塊)處理這些腳本更佳。

以下是一些例子用來解釋為什么 if 是邪惡的。非專業(yè)人士, 請勿模仿!

# 這里收集了一些出人意料的坑爹配置來展示 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 的情況下下發(fā)送到后臺的 '/'

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 將會發(fā)出段錯誤信號(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創(chuàng)建的隱式嵌入的location

location ~* ^/if-and-alias/(?<file>.*) {
    alias /tmp/$file;

    set $true 1;

    if ($true) {
        # nothing
    }
}

為什么會這樣且到現(xiàn)在都沒修復這些問題?

if 指令是 rewrite 模塊中的一部分, 是實時生效的指令。另一方面來說, Nginx 配置大體上是陳述式的。在某些時候用戶出于特殊是需求的嘗試, 會在 if 里寫入一些非 rewrite 指令, 這直接導致了我們現(xiàn)處的情況。大多數(shù)情況下他可以工作, 但是…看看上面。 看起來唯一正確的修復方式是完全禁用 if 中的非 rewrite 指令。但是這將破壞很多現(xiàn)有可用的配置, 所以還沒有修復。

如果你還是想知道該如何使用 if

如果你看完了上面所有內(nèi)容還是想使用 if ,請確認你確實理解了該怎么用它。一些比較基本的用法可以在這里找到。

做適當?shù)臏y試

我已經(jīng)警告過你了!

文章選自:http://xwsoul.com/posts/761 TODO:這個文章后面需要自己翻譯,可能有版權(quán)問題:https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/