本文介绍了JQuery的停留在CORS preflight和IIS响应鬼的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

限时删除!!

我被困 认真... 的 - 解决。阅读:)

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的事情:http://stackoverflow.com/a/10232313/1407618

推荐答案

勾选此的。这可能会帮助你。

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

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

1403页,肝出来的..

09-07 02:52