NGINX hashbang重写 [英] NGINX hashbang rewrite

问题描述

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

  http://example.com/about/staff 
  

会转到

  http://example.com /＃！/ about / staff 
  

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

对于片段标识符不应/不应该（某些有问题的客户端可能会发送它们）出现在HTTP请求中，因此无论Web服务器如何，都不能有重写规则来匹配它们。

HTTP引擎无法对此做出任何假设。如果您尝试对/＃进行初始请求/重定向到/＃！

而不是服务根索引，最终会出现重定向太多的错误，因为客户端会再次询问/（记住它不会发送带有请求的＃）。 您需要使用javascript代替索引文档。

底线是它在服务器端不可用GET请求。即使卷曲已修补没有任何更多的发送。

您可以使用nginx位置指令来使所有其他命令都可以触发前端控制器：

  location = / {
} 
 
位置= /index.html {
} 
 
位置〜/ {
重写^ /＃！$ uri重定向; 
休息; 
} 
  

请注意这种方法; http://jenitennison.com/blog/node/154 更详细地介绍了Gawker的hashbang崩溃以及围绕其使用的其他问题。

I'm wondering what a location or rewrite nginx directive for hashbang (#!) urls would look like. Basically routing all non hash-banged url's through the hashbang like a front controller. So:

http://example.com/about/staff

would route to

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

I'm unclear what the best technique here would be? Whether writing an if statement to check existence of the hashbang, or just a generic rewrite that filters all requests...

解决方案

GETs for fragment identifiers don't/shouldn't (some buggy clients may send them) appear in an HTTP request, so you can't have a rewrite rule to match them, regardless of webserver.

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

If you tried to make the initial request for / redirect to /#! rather than serving the root index, you'd end up with a "too many redirects" error, as the client would come back asking for / again (remember that it won't send the # with its request). You'll need to do this with javascript instead for the index document.

The bottom line is that it's not available server-side in the GET request. Even curl has been patched not to send it any more.

You could have nginx location directives to make everything else hit the front controller though:

 location = / {
  }      

  location = /index.html {
  }      

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

Beware of this approach though; http://jenitennison.com/blog/node/154 goes into a lot more detail about the hashbang debacle at Gawker and other issues surrounding its use.

这篇关于NGINX hashbang重写的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！