Azure中的预检选项检查选项？

Question

我正构建一个简单的ServiceStack应用程序，并打算在AzureWebSites上托管它。这很好。我需要CORS才能使应用程序正常运行。在IIS Express和IIS 7.5本地，这可以正常工作 - 但不适用于Azure或AppHarbor。

实际的AJAX GET和POST请求工作正常，问题是飞行前OPTIONS检查返回空响应;没有标题，没有。

代码在GitHub上。你可以在git commit history中看到我尝试过的一些事情。

我启用了失败的请求记录 - 但这并没有帮助。我没有收到400+系列错误代码 - 我根本没有得到任何回复。

编辑：感谢@paaschpa，我开始从不同的机器上查看问题。从Linux机器添加了一个响应。它表明cURL正在回归奇怪的东西（见下文），导致它根据这个问题输出调试： Why is cURL returning "additional stuff not fine"?

当我从Rackspace Linux机器上测试Azure时，我得到了这个：

kyleh@media:~$ curl -X curl -X OPTIONS -H "Origin: http://www.example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: X-Requested-With" --verbose http://sstodo.azurewebsites.net/items
* About to connect() to sstodo.azurewebsites.net port 80 (#0)
*   Trying 23.101.118.145...
* connected
* Connected to sstodo.azurewebsites.net (23.101.118.145) port 80 (#0)
> OPTIONS /items HTTP/1.1
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.3.4 libidn/1.25 libssh2/1.4.2 librtmp/2.3
> Host: sstodo.azurewebsites.net
> Accept: */*
> Origin: http://www.example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
> 
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Length: 0
< Vary: Accept
< Server: Microsoft-IIS/8.0
< X-Powered-By: ServiceStack/4.036 Win32NT/.NET
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Headers: Content-Type
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Set-Cookie: ARRAffinity=f1d67e2939c9eab291aa7a92c2c5cffe872dc89340409c771374fbf6bc961bd3;Path=/;Domain=sstodo.azurewebsites.net
< Date: Sun, 01 Feb 2015 02:57:55 GMT
< 
* Connection #0 to host sstodo.azurewebsites.net left intact
* Closing connection #0

当我在本地测试网站时，结果为looks right。这是本地结果（VS / IIS Express）：

curl -X OPTIONS 
 -H "Origin: http://www.example.com" 
 -H "Access-Control-Request-Method: POST" 
 -H "Access-Control-Request-Headers: X-Requested-With"
 --verbose http://localhost:1061/items
* timeout on name lookup is not supported
* About to connect() to localhost port 1061 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 1061 (#0)
> OPTIONS /items HTTP/1.1
> User-Agent: curl/7.26.0
> Host: localhost:1061
> Accept: */*
> Origin: http://www.example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
>
< HTTP/1.1 200 OK
< Cache-Control: private
< Vary: Accept
< Server: Microsoft-IIS/8.0
< X-Powered-By: ServiceStack/4.036 Win32NT/.NET
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Headers: Content-Type
< X-AspNet-Version: 4.0.30319
< X-SourceFiles: =?UTF-8?B?QzpccHJvamVjdHNcc2VydmljZXN0YWNrLXRvZG8tYmFja2VuZFxUb0RvQmFja2VuZFxUb0RvQmFja2VuZFxpdGVtcw==?=
< X-Powered-By: ASP.NET
< Date: Thu, 22 Jan 2015 23:51:29 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact
* Closing connection #0

这是IIS7.5本地的结果：

curl -H "Origin: http://www.example.com" -H "Access-Control-Request-Method: P
OST" -H "Access-Control-Request-Headers: X-Requested-With" -X OPTIONS --verbose
 http://localhost/sstodo/items
* timeout on name lookup is not supported
* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 80 (#0)
> OPTIONS /sstodo/items HTTP/1.1
> User-Agent: curl/7.26.0
> Host: localhost
> Accept: */*
> Origin: http://www.example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
>
< HTTP/1.1 200 OK
< Cache-Control: private
< Vary: Accept
< Server: Microsoft-IIS/7.5
< X-Powered-By: ServiceStack/4.036 Win32NT/.NET
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Headers: Content-Type
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Sat, 24 Jan 2015 02:44:55 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact
* Closing connection #0

当我针对AzureWebSites（和AppHarbor）运行测试时，它没有。

curl -X OPTIONS 
 -H "Origin: http://www.example.com" 
 -H "Access-Control-Request-Method: POST" 
 -H "Access-Control-Request-Headers: X-Requested-With" 
 --verbose http://sstodo.azurewebsites.net/items
* timeout on name lookup is not supported
* About to connect() to sstodo.azurewebsites.net port 80 (#0)
*   Trying 23.101.118.145...
* connected
* Connected to sstodo.azurewebsites.net (23.101.118.145) port 80 (#0)
> OPTIONS /items HTTP/1.1
> User-Agent: curl/7.26.0
> Host: sstodo.azurewebsites.net
> Accept: */*
> Origin: http://www.example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
>
* Empty reply from server
* Connection #0 to host sstodo.azurewebsites.net left intact
curl: (52) Empty reply from server
* Closing connection #0

这里的AppHarbor：

curl -X OPTIONS 
 -H "Origin: http://www.example.com" 
 -H "Access-Control-Request-Method: POST" 
 -H "Access-Control-Request-Headers: X-Requested-With" 
 --verbose http://sstodo.apphb.com/items
* timeout on name lookup is not supported
* About to connect() to sstodo.apphb.com port 80 (#0)
*   Trying 50.17.211.206...
* connected
* Connected to sstodo.apphb.com (50.17.211.206) port 80 (#0)
> OPTIONS /items HTTP/1.1
> User-Agent: curl/7.26.0
> Host: sstodo.apphb.com
> Accept: */*
> Origin: http://www.example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
>
* Empty reply from server
* Connection #0 to host sstodo.apphb.com left intact
curl: (52) Empty reply from server
* Closing connection #0

我有点失去方向。在我的心理模型中，我应该能够在我的本地环境中重现问题。我在Azure和AppHarbor中看到的所有文档都表明它们并未阻止OPTIONS调用，但似乎并非如此。

我当然不太关心网站在cURL中的运作方式。

Answer 1

我打赌你遇到了同样的问题; ＆＃34;网络安全＆＃34;在OS X笔记本电脑上运行的Cisco VPN客户端中的模块正在拦截您的HTTP请求，并默默地丢弃作为CORS预检的一部分而发出的OPTIONS请求。多么棒的＆＃34;功能＆＃34;这个VPN软件。它甚至会在您不使用VPN时执行此操作。

切换到https会修复此错误，因为代理无法读取您的请求，因此无法删除OPTIONS。

有关此问题的更多信息，请访问：http://www.bennadel.com/blog/2559-cisco-anyconnect-vpn-client-may-block-cors-ajax-options-requests.htm

您可以使用以下方式卸载Web安全模块： sudo /opt/cisco/anyconnect/bin/websecurity_uninstall.sh

Answer 2

嗯......不确定这会有什么帮助，但我的机器上有一部作品＆＃39;为了你。屏幕截图如下......

如果您修复了自己的问题，我很想知道修复问题。

Answer 3

最后，有效的是切换到HTTPS。

我不能说我理解为什么，但使用HTTPS始终可以解决问题。