¿Por qué se envía una solicitud de OPCIONES y puedo desactivarla?

Por favor refiérase a esta respuesta sobre la necesidad real de una solicitud de OPCIONES pre-flighted: CORS - ¿Cuál es la motivación detrás de la introducción de solicitudes de preflight?

Para deshabilitar la solicitud de OPCIONES, se deben cumplir las siguientes condiciones para la solicitud ajax:

1. La solicitud no establece encabezados HTTP personalizados como 'application/xml' o 'application/json', etc
2. El método request tiene que ser uno de GET, HEAD o POST. Si POST, el tipo de contenido debe ser uno de application/x-www-form-urlencoded, multipart/form-data, o text/plain

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

Han pasado por este problema, a continuación está mi conclusión a este problema y mi solución.

De acuerdo con la estrategia CORS (le recomiendo que lea al respecto) No puede forzar al navegador a dejar de enviar solicitudes de OPCIONES si cree que es necesario.

Hay dos maneras en que puedes evitarlo

• 1. Asegúrese de que su solicitud es una "solicitud simple"
• 1. Establece Access-Control-Max-Age para la OPCIÓN solicitud

Solicitud simple

Una solicitud simple entre sitios es aquella que cumple todas las siguientes condiciones:

Los únicos métodos permitidos son: - CONSEGUIR - CABEZA - POST

Aparte de los encabezados establecidos automáticamente por el agente de usuario (por ejemplo, Conexión, Agente de usuario, etc.), los únicos encabezados que se permiten configurar manualmente son: - Aceptar - Aceptar-Idioma - Contenido-Idioma - Content-Type

Los únicos valores permitidos para el encabezado Content-Type ser: - application / x-www-form-urlencoded - multipart/form-data - text/plain

Una solicitud simple no causará una solicitud de OPCIÓN de pre-vuelo.

Establecer una caché para la OPCIÓN check

Puede establecer un Access-Control-Max-Age para la solicitud de OPCIÓN, de modo que no vuelva a comprobar el permiso hasta que haya expirado.

Access-Control-Max-Age proporciona el valor en segundos durante cuánto tiempo se puede almacenar en caché la respuesta a la solicitud de comprobación previa sin enviar otra comprobación previa solicitud.

Sí es posible evitar la solicitud de opciones. La solicitud de opciones es una solicitud de comprobación previa cuando envía (publica) cualquier dato a otro dominio. Es un problema de seguridad del navegador. Pero podemos usar otra tecnología: iframe transport layer. Le recomiendo encarecidamente que se olvide de cualquier configuración de CORS y utilice la solución readymade y funcionará en cualquier lugar.

Echa un vistazo aquí: https://github.com/jpillora/xdomain

Y trabajando ejemplo: http://jpillora.com/xdomain /

Que tenga un buen día!

Cuando tenga la consola de depuración abierta y la opción Disable Cache activada, siempre se enviarán solicitudes de comprobación previa (es decir, antes de cada solicitud). si no deshabilita la caché, se enviará una solicitud previa al vuelo solo una vez (por servidor)

Como ya se mencionó en publicaciones anteriores, OPTIONS las solicitudes están ahí por una razón. Si tiene un problema con grandes tiempos de respuesta de su servidor (por ejemplo, conexión en el extranjero), también puede hacer que su navegador almacene en caché las solicitudes de comprobación previa.

Haga que su servidor responda con el encabezado Access-Control-Max-Age y para las solicitudes que van al mismo extremo, la solicitud de comprobación previa se habrá almacenado en caché y ya no se producirá.

Para un desarrollador que entiende la razón por la que existe, pero necesita acceder a una API que no maneja llamadas de OPCIONES sin autorización, necesito una respuesta temporal para poder desarrollar localmente hasta que el propietario de la API agregue el soporte adecuado de SPA CORS o tenga una API proxy en funcionamiento.

Encontré que puedes desactivar CORS en Safari y Chrome en una Mac.

Deshabilitar la política de mismo origen en Chrome

Chrome: Salir de Chrome, abrir un terminal y pegar este comando: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir

Safari: Deshabilitar la política del mismo origen en Safari

Si desea deshabilitar la política del mismo origen en Safari (tengo la versión 9.1.1), solo necesita habilitar el menú desarrollador y seleccionar "Deshabilitar restricciones de origen cruzado" en el menú desarrollo.

He resuelto este problema como.

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();
}

Es solo para el desarrollo. Con esto estoy esperando 9ms y 500ms y no 8s y 500ms. Puedo hacer eso porque la aplicación JS de producción estará en la misma máquina que la producción, por lo que no habrá OPTIONS pero el desarrollo es mi local.

No puede, pero podría evitar CORS usando JSONP.

Después de pasar un día y medio tratando de resolver un problema similar, descubrí que tenía que ver con IIS.

Mi proyecto Web API se configuró de la siguiente manera:

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

No tenía opciones de configuración específicas de CORS en la web.config > sistema.Nodo de servidor web como he visto en tantos mensajes

No hay código CORS específico en el global.asax o en el controlador como decorador

El problema fue la configuración del grupo de aplicaciones .

El modo de canalización administrada se estableció en clásico ( lo cambió a integrado ) y la identidad se estableció en Servicio de red (lo cambió a ApplicationPoolIdentity)

Cambiar esa configuración (y actualizar el grupo de aplicaciones) lo arregló para mí.

Lo que funcionó para mí fue importar "github.com/gorilla/handlers" y luego usarlo de esta manera:

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)))

Tan pronto como ejecuté una solicitud POST Ajax y adjuntando datos JSON a ella, Chrome siempre añadiría el encabezado Content-Type que no estaba en mi configuración anterior AllowedHeaders.

Creo que está enviando una solicitud a cross domain.

Para las solicitudes cross-domain, establecer el tipo de contenido en cualquier otro que application/x-www-form-urlencoded, multipart/form-data, o text / plain activará el navegador para enviar un preflight OPTIONS solicitud al servidor.

Por lo que es posible que deba especificar ContentType para evitar la solicitud de OPCIONES.

Jquery Ejemplo: -

$.ajax({
    url: "http://crossdomainurl",
    type: "POST",
    contentType: 'text/plain'
}); 

Tal vez haya una solución (pero no la probé) : podría usar CSP (Content Security Policy) para habilitar su dominio remoto y los navegadores tal vez omitan la verificación de solicitud de OPCIONES CORS.

Si encuentro algo de tiempo, lo probaré y actualizaré este post !

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

Especificación CSP: https://www.w3.org/TR/CSP /

Una solución que he utilizado en el pasado - digamos que su sitio está en mydomain.com, y usted necesita hacer una solicitud ajax para foreigndomain.com

Configure una reescritura de IIS desde su dominio al dominio extranjero, por ejemplo,

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

En su mydomain.com sitio-a continuación, puede hacer una misma solicitud de origen, y no hay necesidad de ninguna solicitud de opciones:)

Se puede resolver en caso de uso de un proxy que intercepte la solicitud y escriba las cabeceras apropiadas. En el caso particular del barniz estas serían las reglas:

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;
}

}