Perché viene inviata una richiesta OPTIONS e posso disabilitarla?

Sto creando un'API Web. Ho trovato ogni volta che utilizzo Chrome per POST, ARRIVO alla mia API, c'è sempre una richiesta OPTIONS inviata prima della richiesta reale, il che è abbastanza fastidioso. Attualmente ottengo che il server ignori qualsiasi richiesta OPTIONS. Ora le mie domande sono utili per inviare una richiesta OPTIONS per raddoppiare il carico del server? Esiste un modo per impedire completamente al browser di inviare richieste OPTIONS?

modifica 13/09/2018 : aggiunte alcune precisazioni su questa richiesta pre-volo e su come evitarlo alla fine di questa risposta.

OPTIONSle richieste sono ciò in cui chiamiamo pre-flightrichieste Cross-origin resource sharing (CORS).

Sono necessari quando si effettuano richieste tra origini diverse in situazioni specifiche.

Questa richiesta pre-volo viene fatta da alcuni browser come misura di sicurezza per garantire che la richiesta in corso sia considerata attendibile dal server. Ciò significa che il server comprende che il metodo, l'origine e le intestazioni inviati sulla richiesta sono sicuri su cui agire.

Il tuo server non dovrebbe ignorare ma gestire queste richieste ogni volta che stai tentando di fare richieste incrociate.

Una buona risorsa può essere trovata qui http://enable-cors.org/

Un modo per gestirli per sentirsi a proprio agio è assicurarsi che per qualsiasi percorso con OPTIONSmetodo il server invii una risposta con questa intestazione

Access-Control-Allow-Origin: *

Questo dirà al browser che il server è disposto a rispondere alle richieste da qualsiasi origine.

Per ulteriori informazioni su come aggiungere il supporto CORS al server, consultare il diagramma di flusso seguente

http://www.html5rocks.com/static/images/cors_server_flowchart.png

modifica 13/09/2018

La OPTIONSrichiesta CORS viene attivata solo in alcuni casi, come spiegato nei documenti MDN :

Alcune richieste non attivano un preflight CORS. Quelle sono chiamate "richieste semplici" in questo articolo, sebbene la specifica Fetch (che definisce CORS) non usi quel termine. Una richiesta che non attiva un preflight CORS, una cosiddetta "richiesta semplice", è una che soddisfa tutte le seguenti condizioni:

Gli unici metodi consentiti sono:

• OTTENERE
• TESTA
• INVIARE

A parte le intestazioni impostate automaticamente dall'agente utente (ad esempio Connessione, Utente-Agente o una qualsiasi delle altre intestazioni con nomi definiti nelle specifiche di recupero come "nome di intestazione proibito"), le uniche intestazioni che possono essere impostati manualmente sono quelli che la specifica Fetch definisce come "intestazione di richiesta con elenco sicuro CORS", che sono:

• Accettare
• Accept-Language
• Content-Language
• Tipo di contenuto (ma notare i requisiti aggiuntivi di seguito)
• DPR
• downlink
• Salvare i dati
• Finestra-Width
• Larghezza

Gli unici valori consentiti per l'intestazione Content-Type sono:

• application / x-www-form-urlencoded
• multipart / form-data
• text / plain

Nessun listener di eventi è registrato su qualsiasi oggetto XMLHttpRequestUpload utilizzato nella richiesta; questi sono accessibili usando la proprietà XMLHttpRequest.upload.

Nessun oggetto ReadableStream viene utilizzato nella richiesta.

Ho superato questo problema, di seguito sono riportate le mie conclusioni su questo problema e la mia soluzione.

Secondo la strategia CORS (consiglio vivamente di leggerlo) Non puoi semplicemente forzare il browser a interrompere l'invio della richiesta OPTIONS se ritiene che sia necessario.

Esistono due modi per aggirare il problema:

1. Assicurati che la tua richiesta sia una "richiesta semplice"
2. Impostare Access-Control-Max-Ageper la richiesta OPTIONS

Semplice richiesta

Una semplice richiesta tra siti è quella che soddisfa tutte le seguenti condizioni:

Gli unici metodi consentiti sono:

• OTTENERE
• TESTA
• INVIARE

A parte le intestazioni impostate automaticamente dal programma utente (ad es. Connessione, Utente-Agente, ecc.), Le uniche intestazioni che possono essere impostate manualmente sono:

• Accettare
• Accept-Language
• Content-Language
• Tipo di contenuto

Gli unici valori consentiti per l'intestazione Content-Type sono:

• application / x-www-form-urlencoded
• multipart / form-data
• text / plain

Una semplice richiesta non provocherà una richiesta OPZIONI pre-volo.

Impostare una cache per il controllo OPTIONS

È possibile impostare un Access-Control-Max-Ageper la richiesta OPTIONS, in modo che non controllerà nuovamente l'autorizzazione fino alla scadenza.

Access-Control-Max-Age fornisce il valore in secondi per quanto tempo è possibile memorizzare nella cache la risposta alla richiesta di verifica preliminare senza inviare un'altra richiesta di verifica preliminare.

Limitazione notata

• Per Chrome, il massimo dei secondi Access-Control-Max-Ageè 600che è di 10 minuti, secondo il codice sorgente di Chrome
• Access-Control-Max-AgeFunziona solo per una risorsa ogni volta, ad esempio GETrichieste con lo stesso percorso URL ma query diverse verranno trattate come risorse diverse. Pertanto, la richiesta alla seconda risorsa attiverà comunque una richiesta di verifica preliminare.

Si prega di fare riferimento a questa risposta sull'effettiva necessità di una richiesta OPTIONS pre-decollata: CORS - Qual è la motivazione dietro l'introduzione delle richieste di verifica preliminare?

Per disabilitare la richiesta OPTIONS, le seguenti condizioni devono essere soddisfatte per la richiesta Ajax:

1. La richiesta non imposta intestazioni HTTP personalizzate come 'application / xml' o 'application / json' ecc
2. Il metodo di richiesta deve essere GET, HEAD o POST. Se il POST, tipo di contenuto dovrebbe essere uno dei application/x-www-form-urlencoded, multipart/form-dataotext/plain

Riferimento: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Quando la console di debug è aperta e l' Disable Cacheopzione attivata, le richieste di verifica preliminare verranno sempre inviate (ovvero prima di ogni richiesta). se non disabiliti la cache, una richiesta pre-volo verrà inviata una sola volta (per server)

Sì, è possibile evitare la richiesta di opzioni. La richiesta di opzioni è una richiesta di verifica preliminare quando si inviano (invii) dati a un altro dominio. È un problema di sicurezza del browser. Ma possiamo usare un'altra tecnologia: il livello di trasporto iframe. Consiglio vivamente di dimenticare qualsiasi configurazione CORS e utilizzare la soluzione readymade e funzionerà ovunque.

Dai un'occhiata qui: https://github.com/jpillora/xdomain

Ed esempio funzionante: http://jpillora.com/xdomain/

Per uno sviluppatore che comprende il motivo della sua esistenza ma deve accedere a un'API che non gestisce le chiamate OPTIONS senza autorizzazione, ho bisogno di una risposta temporanea in modo da poter sviluppare localmente fino a quando il proprietario dell'API aggiunge il corretto supporto SPA CORS o ottengo un'API proxy installato e funzionante.

Ho scoperto che puoi disabilitare CORS in Safari e Chrome su un Mac.

Disabilita la stessa politica di origine in Chrome

Chrome: Esci da Chrome, apri un terminale e incolla questo comando: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir

Safari: disabilitazione dei criteri della stessa origine in Safari

Se vuoi disabilitare la stessa politica di origine su Safari (ho 9.1.1), devi solo abilitare il menu sviluppatore e selezionare "Disabilita restrizioni tra le origini" dal menu Sviluppo.

Come già menzionato nei post precedenti, le OPTIONSrichieste sono presenti per un motivo. Se hai un problema con tempi di risposta elevati dal tuo server (es. Connessione oltremare) puoi anche fare in modo che il tuo browser memorizzi nella cache le richieste di verifica preliminare.

Chiedi al tuo server di rispondere con l' Access-Control-Max-Ageintestazione e per le richieste che vanno allo stesso endpoint la richiesta di verifica preliminare sarà stata memorizzata nella cache e non si verificherà più.

Ho risolto questo problema come.

if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Headers: X-Requested-With');
    header("HTTP/1.1 200 OK");
    die();
}

È solo per lo sviluppo. Con questo aspetto 9ms e 500ms e non 8s e 500ms. Posso farlo perché l'app JS di produzione sarà sulla stessa macchina della produzione, quindi non ci sarà altro, OPTIONSma lo sviluppo è il mio locale.

Non puoi ma potresti evitare CORS usando JSONP.

Dopo aver trascorso un'intera giornata e mezza a cercare di risolvere un problema simile, ho scoperto che aveva a che fare con IIS .

Il mio progetto API Web è stato impostato come segue:

// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
    var cors = new EnableCorsAttribute("*", "*", "*");
    config.EnableCors(cors);
    //...
}

Non avevo opzioni di configurazione specifiche CORS nel nodo web.config> system.webServer come ho visto in così tanti post

Nessun codice specifico CORS in global.asax o nel controller come decoratore

Il problema erano le impostazioni del pool di app .

La modalità pipeline gestita è stata impostata su classica ( modificata in integrata ) e Identity è stata impostata su Servizio di rete ( modificata in ApplicationPoolIdentity )

La modifica di tali impostazioni (e l'aggiornamento del pool di app) l'ha risolto per me.

Quello che ha funzionato per me è stato importare "github.com/gorilla/handlers" e quindi usarlo in questo modo:

router := mux.NewRouter()
router.HandleFunc("/config", getConfig).Methods("GET")
router.HandleFunc("/config/emcServer", createEmcServers).Methods("POST")

headersOk := handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type"})
originsOk := handlers.AllowedOrigins([]string{"*"})
methodsOk := handlers.AllowedMethods([]string{"GET", "HEAD", "POST", "PUT", "OPTIONS"})

log.Fatal(http.ListenAndServe(":" + webServicePort, handlers.CORS(originsOk, headersOk, methodsOk)(router)))

Non appena ho eseguito una richiesta POST Ajax e allego dati JSON, Chrome aggiungeva sempre l'intestazione Content-Type che non era nella mia precedente configurazione consentita.

Una soluzione che ho usato in passato: supponiamo che il tuo sito sia su mydomain.com e che tu debba presentare una richiesta Ajax a foreigndomain.com

Configura una riscrittura IIS dal tuo dominio al dominio straniero - ad es

<rewrite>
  <rules>
    <rule name="ForeignRewrite" stopProcessing="true">
        <match url="^api/v1/(.*)$" />
        <action type="Rewrite" url="https://foreigndomain.com/{R:1}" />
    </rule>
  </rules>
</rewrite>

sul tuo sito mydomain.com: puoi quindi effettuare una stessa richiesta di origine e non è necessaria alcuna richiesta di opzioni :)

Può essere risolto in caso di utilizzo di un proxy che intercetta la richiesta e scrive le intestazioni appropriate. Nel caso particolare di Varnish queste sarebbero le regole:

if (req.http.host == "CUSTOM_URL" ) {
set resp.http.Access-Control-Allow-Origin = "*";
if (req.method == "OPTIONS") {
   set resp.http.Access-Control-Max-Age = "1728000";
   set resp.http.Access-Control-Allow-Methods = "GET, POST, PUT, DELETE, PATCH, OPTIONS";
   set resp.http.Access-Control-Allow-Headers = "Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
   set resp.http.Content-Length = "0";
   set resp.http.Content-Type = "text/plain charset=UTF-8";
   set resp.status = 204;
}

}

Esiste forse una soluzione (ma non l'ho testato): potresti usare CSP (Content Security Policy) per abilitare il tuo dominio remoto e i browser potrebbero saltare la verifica della richiesta OPZIONI CORS.

Se trovo un po 'di tempo, lo testerò e aggiornerò questo post!

CSP: https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Security-Policy

Specifiche CSP: https://www.w3.org/TR/CSP/