IIS dirotta la richiesta OPTION preflight CORS

Sto facendo una richiesta POST CORS e impostando l’intestazione Content-Type su json. Questo fa scattare una richiesta OPZIONI di preflight per sparare (questo è buono e atteso)

A questa richiesta OPTIONS viene risposto con un 200 OK, ma questo non proviene dalla mia applicazione WebAPI.

Ho un gestore di messaggi personalizzato sul posto e non viene mai colpito, quindi la richiesta viene ricevuta da IIS prima di colpire ASP.NET a quanto pare.

Ho trovato diversi post sull’argomento e loro dicono quanto segue

  1. Assicurati che WebDav sia disinstallato / rimosso / disabilitato – DONE

  2. Assicurati che OPTIONSVerbHandler sia rimosso / modificato per utilizzare aspnet_isapi.dll – PROVATO ENTRAMBE

  3. Assicurati che extensionlessURLHandler includa il verbo OPTIONS – DONE

Tuttavia, la mia richiesta di opzioni è ancora object di dirottamento. Con ciò intendo, IIS risponde con 200 OK ma non include un’intestazione Access-Control-Allow-Origin nella risposta. Non include questa intestazione perché non sta mai arrivando al mio codice CORS WebAPI che imposterà questa intestazione.

I due post migliori che ho trovato sembrano il mio problema

qui: JQuery bloccato a preflight CORS e risposta fantasma IIS

e qui: http://brockallen.com/2012/10/18/corsiis-and-webdav/

Ho provato ad triggersre la Traccia richiesta non riuscita (FERB) in IIS e l’ho impostato per tracciare tutti i 200 codici di stato. Non vedo mai che le opzioni richieste vengano registrate … Non sono sicuro se questo significa che FERB non tiene traccia delle richieste OPTIONS o se devo cambiare qualcosa nelle impostazioni di FERB per fare in modo che segua le richieste OPTIONS, o se questo è un indizio a qual è il mio problema?

Questo è ASP.NET WebAPI 2.0 in esecuzione su IIS 7.5 (testato anche su IIS 8 e IISExpress con gli stessi risultati) Non importa quale browser (Chrome, FF e IE falliscono tutti allo stesso modo)

Ho provato tutto quello che posso trovare sull’argomento e ancora non riesco a risolvere il mio problema.

Aiutami StackOverflow, sei la mia unica speranza.

Un paio di cose che puoi provare qui, tutte relative a web.config, in primo luogo modificano l’elemento modules per includere l’attributo runAllManagedModulesForAllRequests="true" , come di seguito:

    

Quindi imposta i tuoi gestori sul seguente:

           

Questo dovrebbe fare il trucco, ma se non lo fa, come ultima risorsa puoi forzare IIS a mostrare le intestazioni corrette con il seguente:

           

Fai attenzione al valore del carattere jolly, dovresti davvero impostarlo sul nome del dominio su cui il tuo sito sarà ospitato.

questo è quello che ha funzionato per me dopo 4 ore di ricerca / sperimentazione:

      

Ho avuto lo stesso problema e le seguenti impostazioni di web.config l’hanno risolto per me.

          

Sono stato quindi in grado di gestire manualmente le richieste di CORS OPTIONS in Application_BeginRequest.

Inizialmente utilizzavo la libreria dettagliata in questo post del blog per la gestione delle richieste CORS. Il prodotto su cui sto lavorando richiede però che runAllManagedModulesForAllRequests sia impostato su false. Questo è il motivo per cui ho dovuto impostare un’implementazione personalizzata, ma se non hai quel requisito dovresti provare quella libreria. Ha funzionato benissimo quando ero in grado di eseguire runAllManagedModulesForAllRequests impostato su true.

Ho provato tutti i suggerimenti di cui sopra così come altri che ho trovato su SO e ciò che importava nella mia situazione era che avevamo richiesto il filtro abilitato su IIS e le OPZIONI HTTP Verb non era nella lista dei verbi consentiti. Una volta che l’ho aggiunto, sono riuscito a sistemare il resto.

Nel nostro caso si trattava di filtrare le richieste in IIS disabilitando il verbo OPTIONS al livello dell’applicazione Web di root. Aprire Gestione IIS, fare clic sull’applicazione radice, fare clic su Richiedi filtro, se OPZIONI appare nell’elenco rimuovere o Consenti verbo. Vorrei averlo controllato per primo, come un sacco di tempo perso.

So che questo è un vecchio post, ma ho appena affrontato lo stesso identico problema.

Nella mia situazione, ho installato CORS sia per OWIN che per WebAPI. Il middleware OWIN CORS intercettava la chiamata OPTIONS molto prima che arrivasse alla roba WebAPI. Forse questo può aiutare qualcun altro in futuro.

Ho installato Microsoft.AspNet.WebApi.Cors e Microsoft.Owin.Cors per la mia WebAPI basata su oWin e app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); aggiunto app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); alla configurazione come di seguito:

 public class Startup : IStartup, IAppStartup { public void Configuration(IAppBuilder app) { var config = this.GetInjectionConfiguration(); BootstrapperWebApi bootstrapperWebApi = (BootstrapperWebApi)this.GetBootstrapperWebApi(config); bootstrapperWebApi.Initialize(true) .EnableLogging() .DisableWebApiDefaultExceptionHandler(); WebApiConfig.Register(config); app.UseOwinExceptionHandler(); app.Use(); app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); //others stuff } 

Ho provato tutti i post menzionati ma non ha funzionato per me, quindi ho spostato il mio servizio Web API 2 di ASP.Net in Windows Server 2012 (IIS 8.5) e lo stesso servizio ha funzionato senza alcuna modifica. Quindi il problema era specifico per IIS 7.5 su Windows 7.