Can ASMX be configured to respond to an HTTP 1.1 OPTIONS request?

Question

It seems that ASMX implicitly does not allow the OPTIONS verb. I'm posting this question because I'm using jQuery AJAX calls with POST which first queries the server for available OPTIONS before the POST verb** is issued.

By default Web.config maps all verbs to legacy ASMX, as shown in this partial configuration sample, so everything should be routed properly:

<system.webServer>
    <requestFiltering>
        <verbs>
          <add verb="OPTIONS" allowed="true"/>
          <add verb="GET" allowed="true"/>
          <add verb="POST" allowed="true"/>
        </verbs>
    </requestFiltering>

<handlers>
    <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
       type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

However the HTTP Response is always 405 for an OPTIONS request. For example, the following request is given:

OPTIONS http://localhost:35920/MarkupTransfomer.asmx HTTP/1.1
Host: localhost:35920
Access-Control-Request-Method: POST

and always results in:

HTTP/1.1 405 Method Not Allowed
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727

The jQuery AJAX call looks like the following, a recommendation from a fairly recent Encosia blog post for working with ASMX:

    $.ajax({
        type: "POST",
        contentType: "application/json; charset=utf-8",
        url: "http://localhost:35920/MarkupTransfomer.asmx",
        data: "{'hi'}",
        dataType: "json"
    });

** Note: I don't want to switch the client to use GET instead of POST.

Summary question:
Can I configure ASP.NET to allow ASMX to handle OPTIONS Requests inherently without error?

Other ideas I've considered

• I can look for a way to tell jQuery.ajax(..) not issue the OPTIONS verb before POST?

• If what I'm asking from legacy ASMX isn't possible, I've considered two other potential ideas:

  1. implement a System.Web.IHttpHandler, stick it in the web.config handlers section to manage only the verbs=OPTIONS requests to path=*.asmx outside of the default ASMX behaviour. This would be a doable workaround.
  2. I can switch over to using WCF. However I want to know if ASMX is too unwieldly first.

Before I take action, I want to query the community for things I might have overlooked, or for better options (no pun).

UPDATE #1

Yep, my web service is being hosted on a different domain. Apparently there are a plethora of issues to navigate with Same Original Policy. This update is definitely worthwhile information to the context of the question all things considered!
However I want to ensure this question stays at the ASMX server and HTTP levels. Although I might be facing related browser issues in the near future, those aren't of consequence to solving the HTTP protocol level of this question. Thanks.

Answer 1

Looks like maybe it doesn't apply because I don't see it in the question, but my answer to this was that In the web config I had to remove the instruction to <remove name="OPTIONSVerbHandler" />

Kudos to the person who posted it near the end of this SO question

Answer 2

I don't know that ASMX was ever able to handle OPTIONS, even for AJAX requests. What exactly do you want to return in the case of an OPTIONS verb? What does the client intend by using OPTIONS?

Also, I've looked into this from the point of view of ASP.NET dealing with the OPTIONS verb. In my case, it was prohibited at the level of the root web.config, not at the ASP.NET or ASMX level. The default mapping for that verb is

<add path="*" verb="*" type="System.Web.HttpMethodNotAllowedHandler" validate="True" />

This corresponds to the 405 error you received.