NGINX hashbang重写

时间:2011-03-21 15:48:11

标签: regex hash nginx rewrite

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

http://example.com/about/staff

将路由到

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

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

3 个答案:

答案 0 :(得分:11)

片段标识符的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的混乱局面及其使用的其他问题。

答案 1 :(得分:2)

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

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

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

答案 2 :(得分:-1)

最佳途径是使用try_files指令:

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

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