在Azure网站HTTP OPTIONS请求由于CORS失败 [英] HTTP OPTIONS request on Azure Websites fails due to CORS

问题描述

我最近动了我们从Rackspace公司CloudSites（在Apache / Linux上运行）的服务器到Windows Azure网站。由于移民，都在我们的REST API jQuery的AJAX请求已经开始失败，由于CORS。

I've recently moved our servers from Rackspace CloudSites (running on Apache/Linux) to Windows Azure Websites. Since the migration, all the jQuery AJAX requests on our REST API have started failing due to CORS.

我们使用自定义的标题，所以jQuery让运行的实际API调用之前pre-飞行HTTP OPTIONS请求。问题是，OPTIONS请求似乎并没有达到我的PHP code，转而由其他实体（显然Web服务器），我好像没有控制权返回。

We use custom headers, so jQuery makes a Pre-flight HTTP OPTIONS request before running the actual API calls. The problem is that the OPTIONS request doesn't seem to reach my PHP code and is instead returned by some other entity (obviously the Web Server) which I seem to have no control over.

我一直用下面的头一两年，所以我现在是pretty确保问题不是在PHP code：

I have been using the following headers for a couple of years now so I'm pretty sure the problem isn't in the PHP code:

<?php
    $this->output->set_header("Access-Control-Allow-Origin: *");
    $this->output->set_header("Access-Control-Allow-Methods: GET,POST,DELETE,HEAD,PUT,OPTIONS");
    $this->output->set_header("Access-Control-Allow-Headers: X-Olaround-Debug-Mode, Authorization, Accept");
    $this->output->set_header("Access-Control-Expose-Headers: X-Olaround-Debug-Mode, X-Olaround-Request-Start-Timestamp, X-Olaround-Request-End-Timestamp, X-Olaround-Request-Time, X-Olaround-Request-Method, X-Olaround-Request-Result, X-Olaround-Request-Endpoint" );
?>

我猜问题是特定于Azure的网站，因为code似乎我的机器上工作正常（的Windows 8 / IIS 8.0）为好。我是新来的Azure（一般和基于Windows的主机），所以我必须对如何处理和调试这个问题，因为Azure的网站允许很小的控制几乎没有任何线索。

I'm guessing the problem is specific to Azure Websites since the code seems to working fine on my development machine (Windows 8 / IIS 8.0) as well. I'm new to Azure (and Windows based hosting in general) so I have almost no clue on how to approach and debug this issue since Azure Websites allow very minimal control.

推荐答案

我决定后，因为已经提供了（虽然在技术上是正确的）答案对这个问题的完整解决方案请不要在此特殊情况下为我工作。诀窍是要做到以下几点：

I decided to post a complete solution to this problem since the answers already provided (while technically correct) don't work in this particular case for me. The trick was to do the following:

像@hcoat上面也建议，增加 system.webServer.httpProtocol.customHeaders 是解决这个问题（我已经在我自己尝试过这第一步，但它没有工作）。添加您需要为CORS这里设置的所有自定义页眉和HTTP方法。

Like @hcoat also suggested above, adding system.webServer.httpProtocol.customHeaders was the first step to resolve the issue (I had already tried this on my own before, but it didn't work). Add all the custom headers and HTTP methods you need to set for CORS here.

<httpProtocol>
    <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Methods" value="GET,POST,DELETE,HEAD,PUT,OPTIONS" />
        <add name="Access-Control-Allow-Headers" value="Origin, X-Olaround-Debug-Mode, Authorization, Accept" />
        <add name="Access-Control-Expose-Headers" value="X-Olaround-Debug-Mode, X-Olaround-Request-Start-Timestamp, X-Olaround-Request-End-Timestamp, X-Olaround-Request-Time, X-Olaround-Request-Method, X-Olaround-Request-Result, X-Olaround-Request-Endpoint" />
    </customHeaders>
</httpProtocol>

2。覆盖默认的处理程序，PHP和删除OPTIONSVerbHandler

下一步（由@Bing汉提供的解决方案），是删除 OPTIONSVerbHandler 定义在IIS中，并且还设置自定义 PHP54_via_FastCGI默认，它接受你的额外的HTTP方法处理程序。默认的处理程序只适用于GET，POST和HEAD请求。

2. Override the default handler for PHP and remove OPTIONSVerbHandler

Next step (the solution provided by @Bing Han), is to remove the default OPTIONSVerbHandler defined in IIS, and also set a custom PHP54_via_FastCGI handler which accepts your additional HTTP Methods. The default handler only works with GET, POST and HEAD requests.

<handlers>
    <remove name="OPTIONSVerbHandler" />
    <remove name="PHP54_via_FastCGI" />
    <add name="PHP54_via_FastCGI" path="*.php" verb="GET, PUT, POST, DELETE, HEAD, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK" modules="FastCgiModule" scriptProcessor="D:\Program Files (x86)\PHP\v5.4\php-cgi.exe" resourceType="Either" requireAccess="Script" />
</handlers>

看看这篇文章了解更多详情的内部运作。

这是这是造成最多的问题拼图的最后一块。由于IIS已经加入＆LT; customHeaders＆GT; ，我在上面的问题分享了PHP code片段被复制它们。这引起在浏览器级的问题而没有很好的相同类型的多个标头响应

This was the final piece of the puzzle that was causing the most problems. Since IIS was already adding <customHeaders>, the PHP code snippet I shared in the question above was duplicating them. This caused problems at the browser level which didn't respond well to multiple headers of the same type.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Imported Rule 1" stopProcessing="true">
                    <match url="^(.*)$" ignoreCase="false" />
                    <conditions logicalGrouping="MatchAll">
                        <add input="{R:1}" pattern="^(dir_path\.php|lolaround|lolaround\.php|app_assets)" ignoreCase="false" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="lolaround.php/{R:1}" />
                </rule>
                <rule name="Imported Rule 2" stopProcessing="true">
                    <match url="lolaround/(.*)" ignoreCase="false" />
                    <action type="Rewrite" url="/lolaround.php/{R:1}" />
                </rule>
            </rules>
        </rewrite>
        <httpProtocol>
            <customHeaders>
                <add name="Access-Control-Allow-Origin" value="*" />
                <add name="Access-Control-Allow-Methods" value="GET,POST,DELETE,HEAD,PUT,OPTIONS" />
                <add name="Access-Control-Allow-Headers" value="Origin, X-Olaround-Debug-Mode, Authorization, Accept" />
                <add name="Access-Control-Expose-Headers" value="X-Olaround-Debug-Mode, X-Olaround-Request-Start-Timestamp, X-Olaround-Request-End-Timestamp, X-Olaround-Request-Time, X-Olaround-Request-Method, X-Olaround-Request-Result, X-Olaround-Request-Endpoint" />
            </customHeaders>
        </httpProtocol>
        <handlers>
            <remove name="OPTIONSVerbHandler" />
            <remove name="PHP54_via_FastCGI" />
            <add name="PHP54_via_FastCGI" path="*.php" verb="GET, PUT, POST, HEAD, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK" modules="FastCgiModule" scriptProcessor="D:\Program Files (x86)\PHP\v5.4\php-cgi.exe" resourceType="Either" requireAccess="Script" />
        </handlers>
    </system.webServer>
</configuration>

注意：尽管这两个@hcoat和@Bing汉的回答在这个问题上是有用的，我只能判给赏金其中之一。我决定把它给@Bing汉，因为他的回答让我最接近的解决方案（我无法找到一个方法来添加自己从一个搜索定制的PHP处理程序）。

Note: While both @hcoat and @Bing Han's answers were useful in this problem, I can only award the bounty to one of them. I've decided to give it to @Bing Han because his answer got me closest to the solution (and I wasn't able to find a way to add a custom PHP handler from own searching).

更新：我已经编辑了答案补充用于HTTP DELETE方法，以及这是在原来的答案缺少支持

Update: I've edited the answer to add support for HTTP DELETE method as well which was missing in the original answer.

这篇关于在Azure网站HTTP OPTIONS请求由于CORS失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！