“La ressource demandée n'a pas en charge la méthode http "OPTIONS" ” lors de l'utilisation de EnableCors

Je veux activer la SCRO sur une action spécifique dans un Asp.net l'Api Web. Voici comment je suis en train de le faire:

[Route("api/mycontroller/myaction")]
[HttpPost]
[EnableCors("https://example.com", "*", "post")]
public async Task<IHttpActionResult> MyAction()
{
    ...
}

Mais quand j'envoie une demande d'OPTIONS pour la route, je reçois en retour un message d'erreur: "La ressource demandée n'a pas en charge la méthode http "OPTIONS"." J'ai aussi essayé de supprimer les [HttpPost] annotation en vain.
Ce qui me manque?

  • hmmm, avez-vous essayé tout à l'envoi de la demande de POSTE et de ne pas les OPTIONS? Je pense que quand vous faites un SCRO demande, le navigateur ne les OPTIONS de trucs pour vous dans le fond (je peux me tromper, cependant).
  • La requête POST lui-même fonctionne, mais d'abord le navigateur envoie une requête OPTIONS et d'échec, de sorte qu'il ne se termine jamais jusqu'à l'envoi de la POSTE.
  • [EnableCors("example.com", "*", "post, options")]? Dites à l'action pour les OPTIONS d'acceptation des demandes ainsi que la POST
  • De même. Si j'ajoute l' [HttpOptions] annotation avec [HttpPost], je n'ai pas d'erreur mais alors il essaie d'exécuter la méthode d'action et veut autorisation. EnableCors est censé répondre à des OPTIONS de demande.
InformationsquelleAutor SZH | 2017-08-10
  1. 5

    Vous avez probablement raté le niveau supérieur d'appel à HttpConfiguration.EnableCors, comme décrit ici: https://enable-cors.org/server_aspnet.html.

    Ajouter ce code à votre configuration:

    public static void Register(HttpConfiguration config)
{
    //New code
    config.EnableCors();
}
    • Je pensais que le fait d'appeler config.EnableCors() dans WebApiConfig.cs permettrait de la SCRO pour l'ensemble de l'API. Je ne savais pas que c'est une condition préalable pour utiliser les annotations. J'ai aussi fait avoir OWIN de la SCRO installé, qui je l'ai enlevé que par stackoverflow.com/a/29452419/560722
    InformationsquelleAutor Kirk Larkin
  2. 5

    Pour moi, j'ai ajouté les en-têtes suivants à la demande en ajoutant le code suivant à la Application_BeginRequest fonction de la Mondiale.asax.cs fichier: 

    protected void Application_BeginRequest()
{
    if (Request.Headers.AllKeys.Contains("Origin", StringComparer.CurrentCultureIgnoreCase)
        && Request.HttpMethod == "OPTIONS")
    {
        Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept, Pragma, Cache-Control, Authorization ");
        Response.End();
    }
}

    J'ai une petite idée pourquoi cela fonctionne.
    Par curiosité, j'ai essayé d'ajouter tous les en-têtes à l'aide d'un astérisque, mais alors API Web s'est plaint que l'Autorisation d'en-tête manquait.

    InformationsquelleAutor Ciaran Gallagher
  3. 5

    Pour assurer la OPTIONS demande est prise en charge par le code de l'application et non pas une autre partie du système avant qu'il n'atteigne votre code d'application, vous pouvez essayer d'ajouter les éléments suivants à votre web.config:

    <system.webServer>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <remove name="OPTIONSVerbHandler" />
    <remove name="TRACEVerbHandler" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
</system.webServer>

    Vous devrez peut-être inclure:

    <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS"
  modules="IsapiModule" requireAccess="None"
  scriptProcessor="C:\Windows\System32\inetsrv\asp.dll"
  resourceType="Unspecified" />

    Voir la réponse à IIS détourne de la SCRO OPTIONS de contrôle en amont demande.

    Ou peut-être même juste ceci:

     <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS"
   modules="ProtocolSupportModule" requireAccess="None" />

    Si rien de tout cela sur ses propres œuvres, puis dans votre global.asax ou de tout autre code, vous pourriez essayer:

    if (filterContext.HttpContext.Request.HttpMethod == "OPTIONS")
{
    filterContext.HttpContext.Response.Flush();
}

    ...ou une autre variation sur ce que, par exemple:

    if (Request.Headers.AllKeys.Contains("Origin", StringComparer.OridinalIgnoreCase)
    && Request.HttpMethod == "OPTIONS") {
    Response.Flush();
}

    Indépendamment de ce code spécifique que vous utilisez pour le faire, le point est:

    • assurez-vous que OPTIONS demandes sont en fait d'être pris ou gérées par l'application du code n'est pas pris/gérée par une autre partie du système avant d'atteindre votre code d'application
    • assurez-vous d'avoir explicite de manutention pour OPTIONS requêtes dans votre code d'application
    • faire la OPTIONS de manutention dans le code de votre application il suffit de ne Response.Flush()

    Ou d'une autre approche que je ne suis pas sûr de qui est pertinent à votre situation en tant que code, mais je vais simplement mentionner dans les cas suivants:

    public HttpResponseMessage Options()
{
    var response = new HttpResponseMessage
    {
        StatusCode = HttpStatusCode.OK
    };
    return response;
}
    • Merci pour la réponse très complète, je dois maintenir un site ancien et <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" modules="ProtocolSupportModule" requireAccess="None" /> œuvres.
    InformationsquelleAutor sideshowbarker