在XMLHttpRequest中设置授权标头会改变HTTP动词 [英] Setting Authorization header in XMLHttpRequest changes HTTP verb

问题描述

今天我发现了XMLHttpRequest的一个奇怪的行为。当我调用一个GET服务时，我发现如果我没有设置Authorization头，那么来自firefox的请求是一样的。但是如果我添加了Authorization头文件，firefox首先发送一个带有OPTIONS的请求，然后发送一个GET请求。

我知道动词OPTIONS必须在服务器端处理，但我只是想知道为什么XMLHttpRequest的行为是这样的。虽然这是一个跨域请求，为什么浏览器首先发送OPTIONS请求。为什么添加一个授权标题改变了行为。

这是我的Javascript代码和Fidler Inspector报告。

  var xmlhttp = new XMLHttpRequest（）; 
 var url =xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; 
 xmlhttp.open（'GET'，url，true）; 
 xmlhttp.setRequestHeader（Authorization，xxxxxxxxxxxxxxxxxxx）; 
 xmlhttp.send（null）; 
 xmlhttp.onreadystatechange = function（）{
 alert（OnReadystatechange ++ xmlhttp.readyState ++ xmlhttp.status）; 
 if（xmlhttp.readyState == 4）{
 if（xmlhttp.status == 200）{
 
} 
 else {
 
} 
} 
 else 
 alert（Error  - >+ xmlhttp.responseText）; 
} 
  

以及Authorization Header的提琴手响应

但是当我做不添加授权标题浏览器直接发送GET请求没有OPTIONS请求。

解决方案 OPTIONS 请求用于在实际发送之前预检交叉源 GET 请求。
$ b

与简单请求不同，preflighted请求首先
通过OPTIONS方法向$ b上的资源发送一个HTTP请求$ b其他域，以确定实际请求是否安全
发送。跨站点请求是这样预检的，因为它们可能
对用户数据有影响。特别是，一个请求
preflighted如果：

• 它使用GET，HEAD或POST以外的方法。此外，如果使用POST来发送具有非
  application / x-www-form-urlencoded，multipart / form-data或
  
  的内容类型的请求数据，则文本/简单的，例如如果POST请求使用application / xml或text / xml将XML有效载荷发送到
  
  服务器，那么请求是
  
  预冲。


• 它设置任何不被认为简单的标题。如果标题字段名称是 Accept 的ASCII不区分大小写的匹配项，则称该标题为简单标题，如果它是 Content-Type 的ASCII区分大小写匹配，并且头字段值的媒体类型为（强）> Accept-Language 或 Content-Language 不包括参数）是对应用程序/ x-www-form-urlencoded ， multipart / form-data 或 text / plain 的ASCII区分大小写匹配。 em>。
  

所以在你的情况下，设置Authorization头使得请求被预先指定，因此 OPTIONS 请求。

更多资讯请点击这里

带有预检的跨源请求的规范

Today I found a strange behavior of XMLHttpRequest. When I am calling a GET service I found that if I do not set the Authorization header the request from firefox is same. But if I add the "Authorization" header firefox first send a request with "OPTIONS" then it sends a "GET" request.

I know that the verb "OPTIONS" must be handled in server side but I was just wondering why XMLHttpRequest behaves like this. Though it is a cross domain request, why browser first send the "OPTIONS" request. Why adding a "Authorization" header changes the behavior.

Here is my Javascript code and Fidler Inspector report.

    var  xmlhttp = new XMLHttpRequest();
    var url = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
    xmlhttp.open('GET',url,true);
    xmlhttp.setRequestHeader("Authorization", "xxxxxxxxxxxxxxxxxxx");
    xmlhttp.send(null);
    xmlhttp.onreadystatechange = function() {
            alert("OnReadystatechange + " + xmlhttp.readyState + " " + xmlhttp.status);
           if (xmlhttp.readyState == 4) {
              if ( xmlhttp.status == 200) {

                   }
                   else {

                   }
             }
             else
                   alert("Error ->" + xmlhttp.responseText);
          }

And the fiddler response with Authorization Header

But when I do not add the Authorization header the browser directly sends the GET request no OPTIONS request.

解决方案

The HTTP OPTIONS request is used to "preflight" the cross-origin GET request, before actually sending it.

Unlike simple requests, "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. In particular, a request is preflighted if:

• It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than
  application/x-www-form-urlencoded, multipart/form-data, or
  text/plain, e.g. if the POST request sends an XML payload to the
  server using application/xml or text/xml, then the request is
  preflighted.
• It sets any header that is not considered simple. A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.

So in your case, setting the Authorization header is causing the request to be preflighted, hence the OPTIONS request.

More info here

Spec on Cross-Origin Request with Preflight

这篇关于在XMLHttpRequest中设置授权标头会改变HTTP动词的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！