Location/rewrite规则和浏览器跨域配置

Location路由规则的使用

前面的时候我们讲了Nginx的很多应用，每个虚拟主机里面我们都会配置location这一个指令

这一个指令就是用于匹配用户的访问路由，这一个指令就是用于匹配用户的访问路由。

像我们一般的URL都是有一定的规则，类似下面的这几个配置，有些路径我们需要转发到后端api集群那边，有些的话是静态资源我们直接读取返回。

http://域名:端口/pub/api/xxx/yyyy 就是一个接口路径

http://域名:端口/static/css/xxx 就是一个css路径

http://域名:端口/static/js/xxx 就是一个css路径

回顾下前面配置的文件服务器

server {
        listen       80;
        server_name  aabbccdd.com;
        location /app/img {
          alias /usr/local/software/img/;
        }
  }

这一个location会涉及到正则表达式，如果大家被正则表达式不熟悉的话一定要去学一下，简单回顾几个常用的

^ 以什么开始
$ 以什么结束

这个例子就是 用户访问路径 /api/user 必须是这个才可以命中location
^/api/user$

下面是常用的路径匹配，语法location [ = | ~ | ~* | ^~ ] uri { ...... }

location = /uri
 = 表示精准匹配，只要完全匹配上才能生效

location /uri
不带任何修饰符，表示前缀匹配


location ^~ /uri/
匹配任何已 /uri/ 开头的任何查询并且停止搜索
 

location /
通用匹配，任何未匹配到其他location的请求都会匹配到

注意：
正则匹配
 区分大小写匹配（~）
 不区分大小写匹配（~*）
 优先级(不要写复杂，容易出问题和遗忘)

优先级：精准匹配 > 字符串匹配(若有多个匹配项匹配成功，那么选择匹配长的并记录) > 正则匹配

我们这边来尝试一个案例和对应的匹配结果

server { 
   server_name xdclass.net;   

   location ~^/api/pub$ { 
      ...
    }
}

解释如下
^/api/pub$这个正则表达式表示字符串必须以/开始，以b $结束，中间必须是/api/pub

http://xdclass.net/api/v1 匹配（完全匹配）

http://xdclass.net/API/PUB 不匹配，大小写敏感

http://xdclass.net/api/pub?key1=value1 匹配

http://xdclass.net/api/pub/ 不匹配

http://xdclass.net/api/public 不匹配，不能匹配正则表达式

Rewrite规则的使用

rewrite 地址重定向，实现URL重定向的重要指令，他根据regex(正则表达式)来匹配内容跳转到

语法 rewrite regex replacement[flag]


rewrite ^/(.*)  https://xdclass.net/$1 permanent

# 这是一个正则表达式，匹配完整的域名和后面的路径地址
# replacement部分是https://xdclass.net/$1，$1是取自regex部分()里的内容

• 常用正则表达式：

注意下 rewrite 最后一项flag参数

那只有一个rewrite的应用场景有哪些呢? 我这边举几个很常见的例子

场景一：你访问一个不存在的链接，那我们那边就可以做一个rewrite进行跳转到我们的首页。

场景二：你们网站域名做了更新，比如我们以前叫test.com,新的域名叫 xdclass.net，然后如果用户访问 test,com 之后我们就可以rewrite到 xdclass.net

场景三：一开始我们的域名是HTTP。后来进行了升级为HTTPS, 那我们就可以在用户访问HTTP之后进行重写到HTTPS。

下面这一个就是我们一个测试的配置，用户访问我们这个域名之后，我们进行跳转到小滴课堂的官网。

这一个rewrite跳转的话，其实它是返回了HTTP状态码是3xx开头的重定向，然后我们浏览器那边进行二次的跳转，

通过下面这一个的HTTP请求响应头信息，我们可以发现跳转的的流程。

浏览器跨域配置

关于跨域，不管你是前端开发还是后端开发，肯定很多同学和有遇到，那首先我们需要先知道什么是跨域？

这个来源是浏览器同源策略 1995年，同源政策由 Netscape 公司引入浏览器。目前所有浏览器都实行这个政策。最初它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页"同源"。

所谓"同源"指的是"三个相同", 就下面的三个

协议相同  http https
域名相同  www.xdclass.net
端口相同  80  81

一句话：浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域

浏览器控制台跨域提示：
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

知道了什么是跨域，那我们如何去解决呢？有很多种解决方法，我这边把他归为两大类

第一类是 JSONP，第一类是。这一个的话目前用的比较少，这一块不太灵活。

第二类是 Http响应头配置允许跨域，第二类配置跨越的话也有两种方式，

第一种是在我们这个程序代码中通过拦截器去配置我们的跨域的头信息，另外一种就是在Nginx层配置跨域的信息

Nginx开启跨域配置，location下配置

location / { 
    add_header 'Access-Control-Allow-Origin' $http_origin;
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,web-token,app-token,Authorization,Accept,Origin,Keep-Alive,User-Agent,X-Mx-ReqToken,X-Data-Type,X-Auth-Token,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
    add_header Access-Control-Allow-Methods 'GET,POST,OPTIONS';

#如果预检请求则返回成功,不需要转发到后端
  if ($request_method = 'OPTIONS') {
      add_header 'Access-Control-Max-Age' 1728000;
      add_header 'Content-Type' 'text/plain; charset=utf-8';
      add_header 'Content-Length' 0;
      return 200;
    }
  
}

那我们工作中一般采用哪一种呢？其实的话比较推荐是在Nginx层网关进行配置。可以根据不同不同的虚拟主机配置哪些系统需要跨越哪些系统，哪些系统不允许跨域，这样的话我们前端人员可以去配置跨域，也可以由后端进行配置。

本篇小结

• 掌握location路由规则的使用
• 掌握rewrite规则的使用
• 掌握nginx配置浏览器跨域