Supporting the HTTP method OPTIONS in Azure RRS feed

  • Question

  • I asked this question on the Azure forum, but have been suggested by the moderator to try it here.

    My problem is the following (I am repeating mostly from my question on the Azure forum):

    I am trying to allow OPTIONS on an Azure WCF site which by default returns a 405 (Method not allowed). The reason to allow OPTIONS is to support CORS preflight requests.

    After scouring through various posts, I suspect I need to do either or both of the following:

    1. IIS configuration set up in Azure through a startup script which uses AppCmd. And this is the AppCmd I understand I should use: %windir%\system32\inetsrv\appcmd set config /section:system.webServer/security/requestfiltering /+verbs.[verb='OPTIONS',allowed='true'] /commit:apphost
    2. Remove the pre-installed WebDAV module through the Web.config script:

    <modules runAllManagedModulesForAllRequests="true"> <remove name="WebDAVModule" /> </modules> <handlers> <remove name="WebDAV" /> <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,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,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,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /> </handlers>

    I have tried both in a simple (i.e. "hello world") WCF service I am trying to host on Azure, and I can't get OPTIONS to work unfortunately. I get the HTTP error code 405 (Method not allowed) when attempting to consume the service (through an HTML app).

    I have uploaded a simple service that demonstrates the problem to

    I have also uploaded a sample HTML app that uses such a service to

    The files of interest are likely to be CustomSettings.cmd and Web.config.

    I have the same service running correctly under IIS7 on a server I have access to. To get OPTIONS working there, I just had to enable it under IIS. I didn't need to write any special code. Click here to see this service in operation. You can replace GET by OPTIONS and you will see that it gets 200 OK.  (One can use this to send OPTIONS to test.)

    The same service is good on Azure for GET, but not for OPTIONS. This is because Azure Web Services do not allow OPTIONS by default (just like the standard IIS7) and the question is how to enable it. The two options that I noted in my question are the popular answers I found on the forum, and unfortunately they do not appear to work.

    QinDian Tang, the moderator of the Azure forum, suggested that I try replacing my WebGetAttribute by WebInvoke(Method="*"). This did get Azure to respond positively (i.e. return 200 OK) to the OPTIONS request.

    However, AspNetCacheProfileAttribute can only be used with GET operations. So with Method="*", I cannot use an AspNetCacheProfile. See also the post by John Lambert at

    The interesting part is that WebGet works just fine with OPTIONS on standard IIS once the relevant headers are set up and the method (i.e. OPTIONS) is enabled. The last post  on this forum  confirms this.

    So the question is how do I get *both* OPTIONS and caching to work on Azure?

    Thanks in advance!

    Thursday, March 21, 2013 12:03 AM

All replies

  • Hi Blue Penguin,

    Welcome to the MSDN forum.

    I am trying to involve a senior expert into your thread. Please wait for the response. Sorry for any inconvenience.

    Good day.

    Alexander Sun [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, March 22, 2013 5:33 AM
  • Thank you Alex for taking this up. I will eagerly watch this space.
    Monday, March 25, 2013 4:57 AM
  • Hello Blue Penguin,

    the cache service and Options feature in seemed independent, they are separate modules in IIS engine.

    so based on your experience, i assumed that the changes you did in WebGetAttribute affected cache service, moreover, though you found that Options seemed working fine in your test as that responded with 200, you can check that more by RDP into your Azure deployment, to see if Options was really enabled there or not.

    back to the other thing you did in one local server with IIS7, you enabled Options there in IIS without any more code changes, that worked fine to host your service with OPTIONS, based on this, it should be supposed that Options in IIS(Azure VM) just need to be enabled by startup task and there should be no changes needed in code part for Options feature, including changing WebGetAttribute .

    so i think you can try this ways to test:

    1. deploy a template web role project on Azure cloud without any startup, then RDP into the deployment VM, manually enable Options in IIS management interface and later manually set up your web service there(it is better to use the same web service which worked fine in the other server you made the web service work via Options), then to see if that works for you. (by this way, you did the same thing as you did and got Options on with other server).
    2. if step 1 fails, then the problem should be related with the Azure VM environment, then compare the Azure VM environemnt with your local server environment, you can find if that is able to  work on Azure.
    3. if step 1 works, then go to a new Azure VM(or diable Options in the Azure VM of step 1), and enable Options by executing command line you did in that startup task, then later manualy set up that web service, to see if finally in this Azure VM, options feature works for you or not.
    4. if step 3 works, that should prove Options feature works fine on Azure VM, then the next step is to check the executing permission of startup task in your original azure project. if step 3 fails but step 1 works, that should prove the command line you used for enabling options feature is not correct, just need to double check the command line to resolve.

    actually, in Azure VM, IIS engine service works as the same as that in your local server, so if the same thing works fine in your local server(windows server 2008 R2), that should  work fine in Azure cloud.

    please try the above steps, hopefully this can bring strong clues or direct workaround. anything happens, feel free to let me know.



    Friday, March 29, 2013 5:59 AM
  • Hi Jian,

    I decided to cheat by using Azure IaaS. A lot simpler and there is 100% control. All good now!

    Thank you for the help.


    Thursday, May 2, 2013 10:34 AM