2

我有一个在我的本地 IIS 实例上运行的 ASP.NET Web API 应用程序。Web 应用程序配置了 CORS。我调用的 Web API 方法如下所示：

[POST("/API/{foo}/{bar}")]
public String DoSomething(String foo, String bar)
{
    return "Hello, World!";
}

客户端，我正在运行以下请求：

$.ajax({
    url: "http://machine/API/Foo/Bar",
    type: "POST",
    success: function (data) {
        console.log("Success: " + data);
    },
    error: function (xhr, status, message) {
        console.log("Failure: " + status + ", " + message);
    }
});

Firefox 15.0.1 中相应的控制台日志内容如下：

test.html (line 38)
POST http://machine/API/Foo/Bar

200 OK
        112ms   
jquery-1.7.2.js (line 8240)

Success: "Hello, World!"

当我访问我的本地 IIS 服务器以及让它访问 Visual Studio 中 IIS Express 开发实例的相应 URL 时，这可以完美地工作。

当我添加单个请求标头时，对我的本地 IIS 服务器发出以下请求时会失败：

$.ajax({
    url: "http://machine/API/Foo/Bar",
    type: "POST",
            onBeforeSend: function (xhr, settings) {
                xhr.setRequestHeader("A", "B");
            },
    success: function (data) {
        console.log("Success: " + data);
    },
    error: function (xhr, status, message) {
        console.log("Failure: " + status + ", " + message);
    }
});

我看到的非常冗长的日志消息是：

Failure: error,

POST在 Visual Studio 中针对 IIS Express 开发实例发出相同的请求时成功。

在 Fiddler 中，无论我的目标是完整的 IIS 服务器还是 Visual Studio 中的 IIS Express，前两个请求都会顺利通过：

// Request
POST http://machine/Foo/Bar HTTP/1.1
Host: machine
Content-Length: 0

// Response
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 38
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 09 Oct 2012 20:16:29 GMT

"Hello, World!"

这些排列{With Headers, Without Headers} x {Full IIS, IIS Express}都在 Fiddler 中产生相同的输出。

简而言之：为什么设置请求标头会导致 AJAX 调用对我的本地完全成熟的 IIS 实例失败？

此外，为什么我的请求在 Fiddler 中成功，但在我的 Javascript 代码中却没有？如果我无法在正确的 IIS 实例中设置请求标头，这将是一个严重的交易破坏者。

4

2 回答 2

1

这可能与跨源资源共享有关。在最近的一个项目中，我们遇到了类似的问题，使用自定义 http 标头的跨源资源共享被证明是问题所在。

仅当 javascript的域与正在进行的 ajax 调用的域不同时才会发生这种情况。

要确定是否是这种情况，您可以尝试在 Global.asax 中添加类似的内容：

protected void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");

    if (HttpContext.Current.Request.HttpMethod == "OPTIONS" )
    {
        //These headers will handle the HTTP OPTIONS call sent by the browser
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods" , "GET, POST" );
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "A, Foo, Bar");
        HttpContext.Current.Response.End();
    }
}

小心不要做这样的事情。将 Access-Control-Allow-Origin 标头设置为“*”值存在安全风险。

附加材料： http ://www.w3.org/TR/cors/

于 2012-10-09T20:40:33.270 回答
0

我的 CORS 问题的实际潜在问题与 IIS 7 使用的管道有关。

当 IIS 7 在经典管道下运行时，请求未与请求一起预检OPTIONS。正如我在问题中描述的那样，他们会默默地失败。我在 Firebug 的 Net 选项卡中看到了这一点，并通过交互式调试与Thinktecture IdentityModel库明确包含在我的解决方案的项目中。

但是当 IIS 7 在集成管道下运行时，CORS 受到尊重。POST请求和具有自定义标头的请求已正确预检。

于 2012-10-31T14:35:49.093 回答