NGINX hashbang重寫

Question

我想知道hashbang（＃！）網址的位置或重寫nginx指令的樣子。基本上通過像前端控制器那樣的hashbang來路由所有非哈希綁定的url。所以：

http://example.com/about/staff 

將路線

http://example.com/#!/about/staff 

我不清楚這裏最好的技術是什麼？無論是編寫一個if語句來檢查hashbang的存在，還是隻是一個通用的重寫過濾所有請求...

Answer 1

GET請求的片段標識符不會/不應該出現在一個錯誤的客戶端中HTTP請求，所以無論Web服務器如何，都不能有重寫規則來匹配它們。

The HTTP engine cannot make any assumptions about it. The server is not even given it.

如果你想做出/重定向到/＃初始請求！而不是服務根索引，最終會出現「重定向太多」的錯誤，因爲客戶端會再次詢問/（記住它不會發送帶有請求的＃）。 您需要使用javascript代替索引文件。

底線是它在GET請求中不可用的服務器端。即使curl has been patched不發送它。

你可以有nginx的位置指令，以使一切撞上了前方控制器，但：

location =/{ 
    }  

    location = /index.html { 
    }  

    location ~/{ 
    rewrite^/#!$uri redirect; 
    break; 
    } 

當心這種方法雖然的; http://jenitennison.com/blog/node/154更詳細地介紹了Gawker的hashbang崩潰和其他使用問題。

Answer 2

由於上述的修改，我只能這樣做重定向特定的電話，正是如此得到任何潛在循環後衛：

location ~ /login|/logout|portfolios|/portfolio/*|/public/* { 
    rewrite^/#!$uri permanent; 
    break; 
} 

請注意，這工作得很好，除了上Safari的瀏覽器所有。 Safari會將您重定向到網址sans the hash。

Answer 3

的最佳途徑是使用try_files指令：

location { 
    try_files $uri $uri/ /index.html; 
} 

假設你index.html文件中包含的JavaScript邏輯路線散列到正確的資源。 URI將保持訪問者請求的內容，而Nginx只是在請求URI沒有找到真正的匹配文件時將請求路由到索引文件。