¿Qué significa status = cancelado para un recurso en las Herramientas para desarrolladores de Chrome?

¿Qué causaría la cancelación de una página? Tengo una captura de pantalla de las Herramientas para desarrolladores de Chrome.

Esto sucede a menudo pero no siempre. Parece que una vez que se almacenan en caché algunos otros recursos, una actualización de la página cargará el LeftPane.aspx. Y lo que es realmente extraño es que esto solo ocurre en Google Chrome, no en Internet Explorer 8. ¿Alguna idea de por qué Chrome cancelaría una solicitud?

Luchamos contra un problema similar en el que Chrome cancelaba solicitudes para cargar cosas dentro de marcos o iframes, pero solo de manera intermitente y parecía depender de la computadora y / o la velocidad de la conexión a Internet.

Esta información está unos meses desactualizada, pero construí Chromium desde cero, busqué en la fuente para encontrar todos los lugares donde las solicitudes podrían cancelarse, y puse puntos de interrupción en todos ellos para depurarlos. De memoria, los únicos lugares donde Chrome cancelará una solicitud:

• El elemento DOM que causó la solicitud se eliminó (es decir, se está cargando un IMG, pero antes de que ocurriera la carga, eliminó el nodo IMG)
• Hiciste algo que hizo innecesario cargar los datos. (es decir, comenzó a cargar un iframe, luego cambió el src o sobrescribió el contenido)
• Hay muchas solicitudes dirigidas al mismo servidor, y un problema de red en solicitudes anteriores mostró que las solicitudes posteriores no funcionarían (error de búsqueda DNS, solicitud anterior (misma) resultó, por ejemplo, código de error HTTP 400, etc.)

En nuestro caso, finalmente lo rastreamos hasta un marco tratando de agregar HTML a otro marco, lo que a veces sucedió antes de que el marco de destino se cargara. Una vez que toca el contenido de un iframe, ya no puede cargar el recurso en él (¿cómo sabría dónde colocarlo?), Por lo que cancela la solicitud.

status = cancelado puede ocurrir también en solicitudes ajax en eventos JavaScript:

<script>
  $("#call_ajax").on("click", function(event){
     $.ajax({
        ...    
     });
  });
</script>

<button id="call_ajax">call</button> 

El evento envía con éxito la solicitud, pero se cancela en ese momento (pero el servidor lo procesa). La razón es que los elementos envían formularios en eventos de clic, sin importar si realiza alguna solicitud ajax en el mismo evento de clic.

Para evitar que se cancele la solicitud, JavaScript event.preventDefault (); tiene que ser llamado:

<script>
  $("#call_ajax").on("click", function(event){
     event.preventDefault();
     $.ajax({
        ...    
     });
  });
</script>

NB: asegúrese de no tener elementos de formulario de ajuste .

Tuve un problema similar en el que mi botón con onclick = {} estaba envuelto en un elemento de formulario. Al hacer clic en el botón, también se envía el formulario, y eso lo estropeó todo ...

Esta respuesta probablemente nunca sea leída por nadie, pero pensé por qué no escribirla :)

Otra cosa a tener en cuenta podría ser la extensión AdBlock, o extensiones en general.

Pero "mucha" gente tiene AdBlock ...

Para descartar extensiones, abra una nueva pestaña en modo incógnito asegurándose de que "permitir en modo incógnito esté desactivado" para las extensiones que desea probar.

Es posible que desee comprobar la etiqueta del encabezado "Opciones de marco X". Si está configurado en SAMEORIGIN o DENY, Chrome (y otros navegadores) cancelarán la inserción de iFrame según las especificaciones .

Además, tenga en cuenta que algunos navegadores admiten la configuración PERMITIR DESDE, pero Chrome no.

Para resolver esto, deberá eliminar la etiqueta de encabezado "Opciones de marco X". Esto podría dejarlo abierto a ataques de clickjacking, por lo que deberá decidir cuáles son los riesgos y cómo mitigarlos.

En mi caso, descubrí que se trata de la configuración de tiempo de espera global de jquery, un tiempo de espera global de configuración de complemento de jquery a 500 ms, de modo que cuando la solicitud supere los 500 ms, Chrome cancelará la solicitud.

Esto es lo que me pasó: el servidor estaba devolviendo un encabezado de "Ubicación" con formato incorrecto para una redirección 302. Chrome no pudo decirme esto, por supuesto. Abrí la página en Firefox e inmediatamente descubrí el problema. Es bueno tener múltiples herramientas :)

Otro lugar en el que hemos encontrado el (canceled)estado es en una configuración incorrecta del certificado TLS en particular. Si un sitio como https://www.example.comestá mal configurado de modo que el certificado no incluye el www.pero es válido para https://example.com, Chrome cancelará esta solicitud y redirigirá automáticamente al último sitio. Este no es el caso de Firefox.

Ejemplo actualmente válido: https://www.pthree.org/

Se me ocurrió una solicitud cancelada al redirigir entre páginas seguras y no seguras en dominios separados dentro de un iframe. La solicitud redirigida se mostró en las herramientas de desarrollo como una solicitud "cancelada".

Tengo una página con un iframe que contiene un formulario alojado por mi pasarela de pago. Cuando se envió el formulario en el iframe, la pasarela de pago redirigiría a una URL en mi servidor. La redirección recientemente dejó de funcionar y terminó como una solicitud "cancelada".

Parece que Chrome (estaba usando Windows 7 Chrome 30.0.1599.101) ya no permitía una redirección dentro del iframe para ir a una página no segura en un dominio separado. Para solucionarlo, me aseguré de que las solicitudes redirigidas en el iframe siempre se enviaran a URL seguras.

Cuando creé una página de prueba más simple con solo un iframe, hubo una advertencia en la consola (que anteriormente me había perdido o tal vez no apareció):

[Blocked] The page at https://mydomain.com/Payment/EnterDetails ran insecure content from http://mydomain.com/Payment/Success

La redirección se convirtió en una solicitud cancelada en Chrome para PC, Mac y Android. No sé si es específico para la configuración de mi sitio web (SagePay Low Profile) o si algo ha cambiado en Chrome.

La versión 33.0.1750.154 m de Chrome cancela constantemente las cargas de imágenes si estoy usando la emulación móvil apuntada a mi host local; específicamente con el agente de usuario spoofing en (frente a sólo configuración de Pantalla).

Cuando desactivo la suplantación de agente de usuario; las solicitudes de imágenes no se cancelan, veo las imágenes.

Todavía no entiendo por qué; en el primer caso, donde se cancela la solicitud, los encabezados de solicitud (PRECAUCIÓN: se muestran los encabezados provisionales) solo

• Aceptar
• Control de caché
• Pragma
• Árbitro
• Agente de usuario

En el último caso, todos esos más otros como:

• Galleta
• Conexión
• Anfitrión
• Aceptar-Codificación
• Aceptar lenguaje

Encogimiento de hombros

Recibí este error en Chrome cuando redirigí a través de JavaScript:

<script>
    window.location.href = "devhost:88/somepage";
</script>

Como ves , olvidé el 'http: //' . Después de agregarlo, funcionó.

Para mi caso, tuve un ancla con evento de clic como

<a href="" onclick="somemethod($index, hour, $event)">

Dentro del evento de clic, tuve una llamada de red, Chrome canceló la solicitud. El anclaje tiene hrefcon ""los medios, se vuelve a cargar la página y al mismo tiempo tiene haga clic con el evento de llamada de red que se cancela. Cada vez que reemplazo el hrefcon vacío como

<a href="javascript:void(0)" onclick="somemethod($index, hour, $event)">

¡El problema se fue!

Aquí hay otro caso de solicitud cancelada por Chrome, que acabo de encontrar, que no está cubierta por ninguna de las respuestas allí.

En pocas palabras
, el certificado autofirmado no es de confianza en mi teléfono Android.

Detalles
Estamos en fase de desarrollo / depuración. La url apunta a un host autofirmado. El código es como:

location.href = 'https://some.host.com/some/path'

Chrome acaba de cancelar la solicitud en silencio, sin dejar ninguna pista para que el novato en el desarrollo web como yo solucione el problema. Una vez que descargué e instalé el certificado con el teléfono Android, el problema desapareció.

Si utiliza algunas solicitudes HTTP basadas en Observable como las integradas en Angular (2+), entonces la solicitud HTTP puede cancelarse cuando se cancela la observación (algo común cuando está utilizando el switchMapoperador RxJS 6 para combinar las transmisiones) . En la mayoría de los casos, es suficiente usar el mergeMapoperador en su lugar, si desea que se complete la solicitud.

Tuve exactamente lo mismo con dos archivos CSS que se almacenaron en otra carpeta fuera de mi carpeta css principal. Estoy usando Expression Engine y descubrí que el problema estaba en las reglas de mi archivo htaccess. Acabo de agregar la carpeta a una de mis condiciones y la arregló. Aquí hay un ejemplo:

RewriteCond %{REQUEST_URI} !(images|css|js|new_folder|favicon.ico)

Por lo tanto, podría valer la pena revisar su archivo htaccess para detectar posibles conflictos

He incrustado todos los tipos de fuente, así como woff , woff2 , ttf cuando incrusto una fuente web en la hoja de estilo. Recientemente noté que Chrome cancela la solicitud de ttf y woff cuando woff2 está presente. Utilizo Chrome versión 66.0.3359.181 en este momento, pero no estoy seguro de cuándo Chrome comenzó a cancelar tipos de fuentes adicionales.

Tuvimos este problema al tener una etiqueta <button>en el formulario, que se suponía que debía enviar una solicitud ajax de js. Pero esta solicitud fue cancelada, debido al navegador, que envía el formulario automáticamente con cualquier clic buttondentro del formulario.

Entonces, si realmente desea usar en button lugar de regular divo spanen la página, y desea enviar un formulario throw js, debe configurar un oyente con preventDefaultfunción.

p.ej

$('button').on('click', function(e){

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

me pasó lo mismo cuando llamé a. archivo js con $. ajax, y hacer una solicitud de ajax, lo que hice fue llamar normalmente.

En mi caso, el código para mostrar la ventana del cliente de correo electrónico provocó que Chrome dejara de cargar imágenes:

document.location.href = mailToLink;

moverlo a $ (ventana) .load (function () {...}) en lugar de $ (function () {...}) ayudó.

En lata, esto ayuda a cualquiera con el que me encontré el estado cancelado cuando omití la devolución false; en el formulario enviar. Esto hizo que el envío ajax fuera seguido inmediatamente por la acción de envío, que sobrescribió la página actual. El código se muestra a continuación, con el importante retorno falso al final.

$('form').submit(function() {

    $.validator.unobtrusive.parse($('form'));
    var data = $('form').serialize();
    data.__RequestVerificationToken = $('input[name=__RequestVerificationToken]').val();

    if ($('form').valid()) {
        $.ajax({
            url: this.action,
            type: 'POST',
            data: data,
            success: submitSuccess,
            fail: submitFailed
        });
    }
    return false;       //needed to stop default form submit action
});

Espero que ayude a alguien.

Para cualquier persona que provenga de LoopbackJS y que intente utilizar el método de flujo personalizado como se proporciona en su ejemplo de gráfico. Estaba recibiendo este error usando un PersistedModel, cambiar a un básico Modelsolucionó mi problema de eventsourcecancelación del estado.

Nuevamente, esto es específicamente para la API de loopback. Y dado que esta es una respuesta superior y superior en Google, pensé que lo lanzaría en la mezcla de respuestas.

Me había enfrentado al mismo problema, en algún lugar profundo de nuestro código teníamos este pseudocódigo:

• crear un iframe

• sobrecarga de iframe enviar un formulario

• Después de 2 segundos, retire el iframe

por lo tanto, cuando el servidor tarda más de 2 segundos en responder, se eliminó el iframe al que estaba escribiendo la respuesta, pero la respuesta aún no se había escrito, pero no había ningún iframe para escribir, por lo tanto, Chrome canceló la solicitud, por lo tanto, para evitar esto, me aseguré de que el iframe se elimine solo después de que termine la respuesta, o puede cambiar el objetivo a "_blank". Por lo tanto, una de las razones es: cuando el recurso (iframe en mi caso) en el que está escribiendo algo, se elimina o se elimina antes de dejar de escribir en él, la solicitud se cancelará

Para mí, el estado 'cancelado' se debía a que el archivo no existía. Extraño por qué el cromo no se muestra 404.

Fue tan simple como un camino incorrecto para mí. Sugeriría que el primer paso en la depuración sería ver si puede cargar el archivo independientemente de ajax, etc.

Las solicitudes podrían haber sido bloqueadas por un complemento de protección de seguimiento.

Me pasó al cargar 300 imágenes como imágenes de fondo. Supongo que una vez que se agotó el tiempo de espera, canceló todo el resto o alcanzó la solicitud simultánea máxima. necesita implementar un 5 a la vez

Una de las razones podría ser que XMLHttpRequest.abort () fue llamado en algún lugar del código, en este caso, la solicitud tendrá el cancelledestado en la pestaña Red de herramientas para desarrolladores de Chrome.

En mi caso, comenzó a aparecer después de la actualización de Chrome 76.

Debido a algún problema en mi código JS, window.location se actualizaba varias veces, lo que resultó en la cancelación de la solicitud anterior. Aunque el problema estaba presente desde antes, Chrome comenzó a cancelar la solicitud después de la actualización a la versión 76.

Tuve el mismo problema al actualizar un registro. Dentro de save () estaba preparando los datos brutos tomados del formulario para que coincidan con el formato de la base de datos (haciendo muchos mapas de valores de enumeraciones, etc.), y esto cancela de forma intermitente la solicitud de venta. Lo resolví sacando la preparación de datos del save () y creando un método dedicado dataPrep (). Convertí este dataPrep en asíncrono y espero toda la conversión de datos intensiva en memoria. Luego devuelvo los datos preparados al método save () que podría usar en el cliente http put. Me aseguré de esperar en dataPrep () antes de llamar al método put:

aguardar dataToUpdate = aguardar dataPrep (); http.put (apiUrl, dataToUpdate);

Esto resolvió la cancelación intermitente de la solicitud.

Si usas axios, puede ayudarte

// change timeout delay: instance.defaults.timeout = 2500;

https://github.com/axios/axios#config-order-of-precedence