NGINX hashbang重写

Question

我想知道hashbang（＃！）url的位置或重写nginx指令是什么样的。基本上通过像前端控制器一样的hashbang路由所有非哈希的网址。所以：

http://example.com/about/staff

将路由到

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

我不清楚这里最好的技术是什么？是否编写if语句来检查hashbang的存在，或者只是编写一个过滤所有请求的通用重写......

Answer 1

片段标识符的GET不会/不应该（某些错误的客户端可能会发送它们）出现在HTTP请求中，因此无论网络服务器如何，您都无法使用重写规则来匹配它们。

  

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

如果您尝试将/ redirect的初始请求发送到/＃！而不是提供根索引，你最终会出现“太多的重定向”错误，因为客户端会再次请求/（请记住它不会发送＃及其请求）。 您需要使用javascript代替索引文档。

底线是它在GET请求中不可用于服务器端。即使curl has been patched也不再发送它。

你可以使用nginx位置指令来使其他所有内容都击中前端控制器：

 location = / {
  }      

  location = /index.html {
  }      

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

但要注意这种方法; http://jenitennison.com/blog/node/154详细介绍了关于Gawker的混乱局面及其使用的其他问题。

Answer 2

作为对上述内容的修改，我只针对特定调用执行此重定向，因此没有潜在的回调：

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

请注意，除了Safari之外，这适用于所有浏览器。 Safari会将您重定向到没有散列的网址。

Answer 3

最佳途径是使用try_files指令：

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

假设您的index.html文件包含将哈希路由到正确资源的javascript逻辑。 URI将保留访问者请求的内容，而Nginx只是在没有找到请求uri的真实匹配文件时将请求路由到您的索引文件。