问题描述
我被困 认真... 的 - 的解决。阅读:)的
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.
为了实际测试它是否工作,我做了以下内容:
- 我成立了一个简单的HTML页面,并将其发布在不同的主机比其他服务上(的 xttp:// OTHERHOST / simplewebpage 的)。该页面使用jQuery,使样品的要求。 code见下文。
- 接下来我建立了我的休息服务不使用IIS前preSS但我的机器上运行,而它的完全炸毁实例( xttp:// developmenthost / restservice 的)。
- 最后,但我打开xttp不是至少在我的机器:// OTHERHOST / simplewebpage并触发Ajax请求。错误回调执行告诉我有一个传输错误,在浏览器(IE9)或(空字符串)。我确信没有代理相关的连接问题或类似的东西。
- 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.
- 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).
- 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响应鬼的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!