OPCIONES súper lentas de preflight solo en Chrome

Recientemente he estado luchando con un problema súper extraño que solo ocurre en Chrome: como mi API (NodeJS) está en un subdominio diferente, necesito usar CORS para acceder a él desde mi interfaz (EmberJS).

Funciona bastante bien, pero con mucha frecuencia (el 95% del tiempo) tengo consultas OPTIONS muy lentas, lo que retrasa las llamadas a la API unos 3 segundos.

2 peticiones, OPCIONES lleva 3 segundos

La mayor parte de este tiempo se gasta en descargar un contenido vacío:

Descargar un contenido vacío toma 3 segundos

Se vuelve aún más extraño cuando estoy probando esto en otro sitio web que hicimos usando una architecture similar, experimentando exactamente el mismo problema.

Algunas otras cosas que probé:

  • He estado probando esto con Firefox y Safari, y no tuve ningún retraso.
  • He estado intentando esto localmente o en producción, experimentando el mismo retraso.
  • He intentado esto con el modo de incógnito (sin extensiones), y tengo exactamente el mismo problema.

Estamos utilizando en el back-end NodeJS con el paquete CORS .

Ahora, no tengo idea si el problema está en Chrome 60, NodeJS, el paquete CORS o EmberJS + jQuery.

¿Alguien ha experimentado esto también?

Solo como una nota: parece un error de chrome

Reproducí el problema utilizando un servidor con dos nombres DNS utilizando un servicio en un dominio único

 https://domain1.com --> https://domain1.com (No CORS, no delay) https://domain2.com --> https://domain1.com (CORS, delay) 

corsé de cromo

Es exactamente el mismo servicio que responde a dos nombres, por lo que estoy probando exactamente la misma solicitud, código de cliente y servidor (los nombres DNS son intercambiables)

Probado con

  • Chrome 61.0.3163.100 (Windows) -> RETARDO
  • Chrome 62.0.3202.84 (Android) -> DELAY
  • Chrome 62.0.3202.84 (iOS-Ipad) -> OK !!!
  • Firefox -> OK
  • Edge -> OK

Solución (en mi caso). Crear un proxy en mi host para responder al mismo DNS de origen y evitar CORS

He estado buscando depurar esto y parece ser un error de Chrome ya que estábamos experimentando el mismo problema.

Para referencia, he presentado un informe de error a Chrome aquí: CORS antes del vuelo y las solicitudes posteriores son muy lentas solo en Chrome

Estoy agregando esto aquí para ayudar a evitar que más desarrolladores pasen medio día investigándolo;) Se actualizará a medida que aquí hay más de Chromium.

A continuación se presenta una descripción general del informe de errores:

Agente de usuario:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Pasos para reproducir el problema:

  1. Tener app.domain.com
  2. Elemento de lista
  3. Tener api.dominio.com
  4. Habilitar CORS en la API para habilitar el acceso
  5. Verifique las respuestas en DevTools, vea las OPCIONES y las solicitudes GET están tomando hasta 300 ms +

¿Cuál es el comportamiento esperado?

Los tiempos de respuesta deben ser precisos.

¿Qué salió mal?

Estamos utilizando los microservicios Go y notamos una gran disparidad en el tiempo entre los navegadores, siendo el cromo el más lento hasta una magnitud de 100x.

cuando hemos comprobado los tiempos del backend, las respuestas toman a lo sumo 10 ms, y la mayoría son sub 1 ms. Cuando se verificaba el tiempo en los devtools, las mismas respuestas llegaban a ~ 100 ms ~ 1 s.

¿Esto funcionó antes?

N / A

Versión de Chrome: 63.0.3239.132 Canal: versión de SO estable: 10.0 Versión de Flash:

En Firefox (y en cualquier otro navegador), las mismas solicitudes regresan en ~ 1-20ms como se esperaba.

Al intentar diagnosticar más, utilizamos el Fiddler de Telerik para verificar los tiempos de respuesta reales de la red y confirmamos que Chrome los estaba enviando y recibiendo dentro de los tiempos esperados. La única conclusión a la que podríamos llegar es que algo interno de Chrome está ralentizando el procesamiento de estas solicitudes.

Probamos todas las permutaciones de chrome://flags#out-of-blink-cors y chrome://flags#enable-site-per-process , que son las dos opciones que detectamos que parecen vagamente relevantes. Nada parecía ayudar.

También hemos encontrado muchos artículos sobre Desbordamiento de stack sobre problemas similares que hacen mención de que se trata de un error de Chrome, pero no he podido encontrarlo aquí:

Acabamos de probar Chrome en MacOS y no parece ser un problema, por lo que puede estar limitado a Windows.

Cromo: opcionesChrome getChrome

Borde: opcionesEdge getEdge

Firefox: opcionesFirefox getFirefox