Parece que de acuerdo a la CORS Spec, GET y POST solicitudes de forma transparente siga 302 redirecciones. Pero Chrome es la cancelación de mi pedido.

Aquí está el JS que hace la solicitud:

var r = new XMLHttpRequest();
r.open('GET', 'https://dev.mysite.com/rest', true);
r.send();

Aquí es lo que debe ocurrir:

  1. Cliente: XHR petición POST /resto
  2. Servidor: responde con redirección HTTP 302 a /descanso/
  3. Cliente: Siga que redirigir

Pero después del paso 2, Chrome cancela la solicitud. Si no había HTTP 302, la solicitud de trabajo a la perfección. He confirmado esto.

Cuando se ejecuta la solicitud, puedo ver en Chrome de Red del panel de sólo uno XHR — la cancelación de la solicitud POST sin los encabezados de respuesta o la respuesta del cuerpo.

De depuración con Chrome net-internals de la herramienta, veo que no fue una respuesta enviado desde el servidor, y después de eso, se canceló la solicitud. Aquí está la salida de la solicitud:

79295: URL_REQUEST
https://dev.mysite.com/rest
Start Time: 2013-08-30 12:41:11.637

t=1377880871637 [st=    0] +REQUEST_ALIVE  [dt=13455]
t=1377880871638 [st=    1]    URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=1]
                              --> delegate = "extension Adblock Plus"
t=1377880871639 [st=    2]   +URL_REQUEST_START_JOB  [dt=13453]
                              --> load_flags = 143540480 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT)
                              --> method = "POST"
                              --> priority = 2
                              --> upload_id = "0"
                              --> url = "https://dev.mysite.com/rest"
t=1377880871639 [st=    2]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=1377880871639 [st=    2]     +HTTP_STREAM_REQUEST  [dt=7]
t=1377880871646 [st=    9]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                                  --> source_dependency = 79296 (HTTP_STREAM_JOB)
t=1377880871646 [st=    9]     -HTTP_STREAM_REQUEST
t=1377880871646 [st=    9]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=1377880871646 [st=    9]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                                  --> GET /facultyportfolio-rest HTTP/1.1
                                      Host: dev.liberty.edu
                                      Connection: keep-alive
                                      Content-Length: 46
                                      Origin: http://localhost:8080
                                      User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36
                                      Content-Type: application/json; charset=UTF-8
                                      Accept: */*
                                      Referer: http://localhost:8080/ajaxtest.html
                                      Accept-Encoding: gzip,deflate,sdch
                                      Accept-Language: en-US,en;q=0.8
t=1377880871646 [st=    9]        HTTP_TRANSACTION_SEND_REQUEST_BODY
                                  --> did_merge = true
                                  --> is_chunked = false
                                  --> length = 46
t=1377880871646 [st=    9]     -HTTP_TRANSACTION_SEND_REQUEST
t=1377880871646 [st=    9]     +HTTP_TRANSACTION_READ_HEADERS  [dt=1001]
t=1377880871646 [st=    9]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=1000]
t=1377880872646 [st= 1009]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                  --> HTTP/1.1 302 Found
                                      Date: Fri, 30 Aug 2013 16:41:11 GMT
                                      Server: Apache/2
                                      Access-Control-Allow-Origin: http://localhost:8080
                                      Access-Control-Allow-Credentials: true
                                      Location: https://dev.mysite.com/rest/
                                      Content-Language: en-US
                                      Vary: Accept-Encoding,User-Agent
                                      Content-Encoding: gzip
                                      Content-Length: 20
                                      Connection: close
                                      Content-Type: text/plain; charset=UTF-8
t=1377880872647 [st= 1010]     -HTTP_TRANSACTION_READ_HEADERS
t=1377880872647 [st= 1010]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=12445]
t=1377880885091 [st=13454]        CANCELLED
t=1377880885092 [st=13455]   -URL_REQUEST_START_JOB
                              --> net_error = -3 (ERR_ABORTED)
t=1377880885092 [st=13455] -REQUEST_ALIVE

Al final, se puede ver la «Cancelado» a causa de «URL_REQUEST_BLOCKED_ON_DELEGATE». No sé lo que eso significa. Pero de nuevo, si no hay redirección HTTP 302, el error no se produciría.

¿Alguien sabe cuál es la causa de Chrome para cancelar esta solicitud?

4 Comentarios

  1. 23

    Las respuestas que aquí se mezclan, dando a entender en ciertos ajustes en el código, etc. que puede resolver el problema redirigir con CORS, pero el CORS spec especifica claramente cuando tales CORS redirige fallará/pass :
    Según la especificación, los navegadores deben

    1. Permite 3XX redirección , si la solicitud para el recurso redirigido no requiere de pre-verificación de vuelo (simple CORS peticiones sin personalizar encabezado por ejemplo). Ver https://www.w3.org/TR/cors/#simple-cross-origin-request-0

    Si el manual de redirigir la bandera no está definida y la respuesta tiene un código de estado HTTP 301, 302, 303, 307, o 308
    Aplicar la redirección pasos

    1. No permitir 3XX redirección, si la solicitud de recurso redirigido requiere pre-vuelo de verificación. Ver https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0

    Si la respuesta tiene un código de estado HTTP 301, 302, 303, 307, o 308
    Aplicar la caché y de la red de error pasos.

    He explorado diferentes CORS escenarios en la repo de github: https://github.com/monmohan/cors-experiment.

    Este problema específico con error de redirección también puede ser fácilmente reproducido en aislamiento por el paquete aquí: https://github.com/monmohan/cors-experiment/tree/master/issue

    • Sabes por casualidad ¿por qué 30x no está permitida para las solicitudes que requieren comprobaciones? Me encantaría leer algo de fundamento para que la parte de la especificación.
    • Al parecer, la redirección está permitido es un «cambio reciente» (stackoverflow.com/questions/40580913/…) en la especificación, sólo 4 de agosto de 2016, por lo que es tomar un tiempo para que los navegadores para cumplir con la…
  2. 9

    http://httpstatus.es/302

    Si el código de estado 302 es recibido en respuesta a una solicitud que no se ni CABEZA, el agente de usuario NO DEBE redirigir automáticamente la solicitud, a menos que pueda ser confirmado por el usuario, ya que esto puede cambiar las condiciones en que se hizo la petición.

    • Por lo que parece decir que las peticiones GET debería redirigir. Mi petición es un GET, pero no redirecciona.
    • Usted dijo que el paso 1 fue, «Cliente: XHR PUESTO solicitar a /descanso»
    • Oh, lo siento, sí, el problema que estaba sucediendo con el POST al principio, pero también con GET. Tal vez el cambio a un 307 303 o HTTP de código podría funcionar…
    • Consulte stackoverflow.com/questions/40580913/… para una explicación más clara y especificaciones de actualización.
  3. 9

    He encontrado este post sobre configuración de la correcta Access-Control-Allow-Origin encabezado CORS en su respuesta 302 a ser útil, al menos en mi sonido similar caso.

    Investigación del problema, demostró que su XHR no fue el aterrizaje en
    el CORS habilitado URL directamente, sino que estaba siendo redirigido a través de
    un HTTP 302 (redirección) respuesta.

    Así que tenga en mente que la de redireccionar a la URL debe incluir también un
    Access-Control-Allow-Origin encabezado, de lo contrario el navegador dejará de derecho
    allí, con su intento de cruzar solicitud de dominio.

    También he encontrado que el ajuste adicional CORS encabezados por encima y más allá de Access-Control-Allow-Origin menudo resultar en la cancelación de una transacción.

    • Mi petición se hizo recibir un 302, pero la respuesta contenía una adecuada Access-Control-Allow-Origin encabezado. Usted dijo que además de los encabezados de la respuesta puede causar la cancelación? Puede usted explicar esto un poco más, o dar ejemplos de que los encabezados de la causa?
  4. 2

    Yo también tenía el problema de que Chrome no estaba siguiendo una redirección en un CORS solicitud. Para mí, el problema era que el JS-marco yo uso (Sencha Touch) agrega un encabezado de solicitud: X-Pidió-Con: «XMLHttpRequest»

    Tan pronto como me quita este (en Sencha Touch llamando Ext.Ajax.setUseDefaultXhrHeader(false);) trabajó como un encanto.

    No seguro por qué, pero espero que esta información ayude a alguien.

Dejar respuesta

Please enter your comment!
Please enter your name here