JQuery的停留在CORS preflight和IIS响应鬼 [英] JQuery stuck at CORS preflight and IIS ghost response

问题描述

我被困 认真... 的 - 的解决。阅读：）的

I'm stuck. Seriously... - solved. read on :)

场景：我想在这里做正确的事。我加了CORS的功能，我的REST服务（的ASP.NET Web-API）依靠Thinktecture Identitymodel CORS DelegatingHandler。到目前为止好。

Scenario: I'm trying to do the right thing here. I added CORS functionality to my REST Service (ASP.NET Web-API) relying on the Thinktecture Identitymodel CORS DelegatingHandler. So far so good.

为了实际测试它是否工作，我做了以下内容：

1. 我成立了一个简单的HTML页面，并将其发布在不同的主机比其他服务上（的 xttp：// OTHERHOST / simplewebpage 的）。该页面使用jQuery，使样品的要求。 code见下文。


2. 接下来我建立了我的休息服务不使用IIS前preSS但我的机器上运行，而它的完全炸毁实例（ xttp：// developmenthost / restservice 的）。


3. 最后，但我打开xttp不是至少在我的机器：// OTHERHOST / simplewebpage并触发Ajax请求。错误回调执行告诉我有一个传输错误，在浏览器（IE9）或（空字符串）。我确信没有代理相关的连接问题或类似的东西。

1. I set up a simple HTML page and published it on a different host than the rest service (xttp://otherhost/simplewebpage). The page uses JQuery to make the sample request. Code see below.
2. Next I set up my rest service to not use iis express but rather the fully blown instance of it running on my development machine (xttp://developmenthost/restservice).
3. Last but not least on my development machine I open up the xttp://otherhost/simplewebpage and fire the Ajax request. The error callback is executed telling me there was a "transport error" (IE9) or "" (empty string) in Chrome. I made sure there's no proxy related connectivity issue or anything like that.

所以，我出去看了看痕迹提琴手和IIS日志。
菲德勒说，没有GET / REST /你好请求，而是一个选项/ REST /你好要求 - 这是完全正常和预期！但是到OPTIONS请求的响应是相当耐人寻味！

So I went forth and looked at the Fiddler traces and IIS logs. Fiddler says there is no GET /rest/hello request but rather a OPTIONS /rest/hello request - which is totally fine and expected! However the response to the OPTIONS request is rather intriguing!

整体响应头看起来是这样的：的

The whole response header looks like this:

HTTP/1.1 200 OK
Allow: OPTIONS, TRACE, GET, HEAD, POST
Server: Microsoft-IIS/7.5
Public: OPTIONS, TRACE, GET, HEAD, POST
Date: Fri, 15 Feb 2013 14:09:27 GMT
Content-Length: 0

这当然是无处甚至接近预期的反应。 关于这个有趣的部分是，请求甚至没有在我的应用程序打的Application_BeginRequest（）。所以没有办法我的应用程序可以负责这一结果。我可以看到请求我的IIS日志和IIS添加Powered-by-ASP.NET头..所以它肯定通过（右）IIS站点传递。

This is of course nowhere even close to the expected response. The fun part about this is, that the Request didn't even hit Application_BeginRequest() in my application. So there's no way my application could be responsible for that result. I can see the request in my IIS logs and IIS adds the Powered-by-ASP.NET header.. so it definitely passes through (the right) IIS site.

jQuery的code触发Ajax请求：的
    

The JQuery code that triggers the ajax request:

    function Run()
    {
        $.ajax({
            type: 'GET',
            url: url,
            dataType: "json",
            beforeSend: function(jqXhr) {
                jqXhr.setRequestHeader("Authorization", "Basic " + getBasicHttpEncodedString(userName, password));
                jqXhr.setRequestHeader("Api-Key", "123");
            },
            success: successCallback,
            error: errorCallback,
            timeout: 180*1000
        });
    }

由此产生的OPTIONS请求看起来像：的

The resulting OPTIONS request looks like that:

OPTIONS http://services.dev13/Rest/Hello HTTP/1.1
Host: developmenthost
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://otherhost/simplewebpage
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
Access-Control-Request-Headers: accept, origin, api-key, authorization
Accept: */*
DNT: 1
Referer: http://otherhost/simplewebpage
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

...你已经看到，响应之上。

... and you have already seen the response to that above.

任何想法，究竟谁回答我的OPTIONS请求？或者是我的JQuery code有缺陷？
如果我使用例如邮差（谷歌Chrome应用），或者如果我伪造的提琴手请求REST服务工作得很好。（这可能是因为他们没有做CORS协商 - 没有OPTIONS请求）

Any idea who exactly answers my OPTIONS request? Or is my JQuery code flawed? The REST Service works just fine if I use for example Postman (Google Chrome App) or if I forge Requests in Fiddler (That's probably because they don't do CORS negotiation - there's no OPTIONS request).

更新＃1：的今天早些时候，我读的地方，禁用WebDAV是强制性的，因为它与OPTIONS请求干扰。我的IIS角色服务视图告诉我，WebDAV发布是的未安装的

*更新＃2：* 问题解决了？我挖得更深。有一个在IIS中注册的模块，该模块负责不需要的（？）响应OPTIONS请求。它的名字是OPTIONSVerbHandler（处理程序：ProtocolSupportModule）。如果我禁用该模块的要求贯穿于我的申请。还有就是创建一个更有意义的响应，然后的后面跟着实际的GET请求！的 耶！的

* Update #2:* Problem solved?? I dug deeper. There's a module registered in IIS that is responsible for the "undesired(?)" response to the OPTIONS request. Its name is "OPTIONSVerbHandler" (handler: ProtocolSupportModule). If I disable that module the request passes through to my application. There a more meaningful response is created and then followed by the actual GET request! YAY!

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: http://otherhost/simplewebpage
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept,origin,api-key,authorization
X-AspNet-Version: 4.0.30319
Date: Fri, 15 Feb 2013 15:09:25 GMT
Content-Length: 0

一旦你知道哪里出了问题当然是你找到大量资源的告诉你，确保你的web.config看起来像： - / 的

Once you know where the problem is of course you find plenty of resources telling you to make sure your web.config looks like that :-/

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="false">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="OPTIONSVerbHandler" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>

但这并不IE9中工作，但（错误：没有交通工具）。万一有人像我一样去了同一条路 - >这是一个IE9的事情：<一href=\"http://stackoverflow.com/a/10232313/1407618\">http://stackoverflow.com/a/10232313/1407618

推荐答案

勾选此的设置访问控制，允许原产地 - 在网络API 。这可能会帮助你。

Check this set-access-control-allow-origin-in-web-api.This may help you.

这篇关于JQuery的停留在CORS preflight和IIS响应鬼的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！