http://www.nginx.cn/643.html
http://www.xiehaichao.com/articles/428.html
location = /member/checkorder.php {
proxy_pass http://test.www.com/home/order/index;
}
建站过程中进程会遇到搜索引擎收录带www和不带www的@两个域名的同一站点，影响排名。
这时候我们可以把其中一个域名301永久重定向到另一个域名传递权重，不推荐停止解析其中任何一个。
谷歌对301的反应快一些，百度需要一段时候后才能识别301.
举个例子，最近我想做一个查询域名的站点，我注册了域名findname.cc。
我想主要使用findname.cc，访问www.findname.cc会301跳转到findname.cc
首先，设置findname.cc和www.findname.cc解析到同一ip，推荐使用dnspod
其次，设置好域名解析后修改nginx配置文件
修改nginx.conf 的server_name部分
|
1
2
3
4
|
server_name findname.cc www.findname.cc;
if ($host ~* www.findname.cc) {
rewrite ^/(.*)$ http://findname.cc/$1 permanent;
}
|
一、rewrite 对post影响
昨天有个同事跟我咨询他的post请求，rewrite 之后，post的数据没有传过去。遂跟他要了下配置，示意如下：
|
1
2
3
4
5
6
|
看到配置就不难理解了，原因是如果rewrite 后面的参数是以http开头，那么实际就是会redirect，给客户端返回临时重定向302，这时客户端会收到302后对foo.com发起get请求（通过firebug跟踪可见）。所以之前的post请求的数据就不复存在了。上面这种情况应该使用反向代理proxy_pass。
为了测试一下rewrite对post的影响，故设计了如下场景进行测试，以作备忘。
场景：
rewrite 进行外部redirect时，post数据会丢失，内部跳转呢。配置如下
|
1
2
3
4
5
6
7
8
9
10
|
{
servername bar.com
location /abc {
rewrite ^ /123;
}
location /123 {
proxy_pass http://10.4.21.171:3000/myform ;
}
}
（proxy_pass后端是用dancer起的一个处理post表单的程序）
|
bashcmd#curl -d “a=b” http://localhost/abc
测试结果显示后端的myform可以取到post参数，说明rewrite内部跳转时post数据可以传到后端。
分析了下原因应该是：
http协议中对request有如下描述，
Request = Request-Line ; Section 5.1
*（（ general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ） CRLF） ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
request_uri属于Request-Line。
post的数据存放在message_body内，在内部跳转时，nginx实际是把request uri重写了下，又放回request中，所以message_body的数据得以传到后端。
如果内部跳转使用第三方模块echo_location
|
1
2
3
4
|
location /abc {
echo_location /123;
}
post数据也会丢失，因为echo_location实现机制是对重定向的地址进行GET操作。
|
二、rewrite last break 测试
在测试rewrite一般都会遇到last break的问题，每次都是弄明白了，过两天又忘了，为了忘却的纪念，今天就记录一笔，备忘下。
|
1
2
3
4
|
情况一
location /xiehc {
rewrite ^/xiehc/(.*)$ /xiehc/123 last;
}
|
如果这样配置，以last结束，nginx会跳出此location，再重新执行一下“请求处理阶段”(Nginx的请求处理阶段共有 11 个之多,后面会介绍)，这样就会造成死循环,不过nginx有限制，10次后就会报500.（Nginx will hit the 10 cycle limit and return error 500: ）
|
1
2
3
4
5
6
7
|
情况二
location /xiehc {
rewrite ^/xiehc/(.*)$ /xiehc/123 last;
}
location /xiehc/123 {
proxy_pass http://10.4.21.171:3000/myform ;
}
|
这种配置，请求/xiehc后，最终myform可以执行，因为如上所描述，请求会跳出上面的location，重新执行请求处理阶段，并search一个匹配的location，这时就找到了/xiehc/123，然后就是代理到后端myform。
|
1
2
3
4
|
情况三
location /xiehc {
rewrite ^/xiehc/(.*)$ /xiehc/123 break;
}
|
如果是break结尾，那么请求不会出这个location，直接对/xiehc/123进行文件系统的映射，如果文件系统不存在此目录或文件，就会报错，不会出去此location祸害别人，正如此，如果是情况二，使用break结束，那么那个pass_proxy就不会被执行。
