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

402

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

Recurso cancelado

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?

Styfle
fuente
13
Es posible que pueda obtener más detalles de un seguimiento de red interna . Tuve un problema similar y descubrí en mi caso que la cancelación estaba net::ERR_ABORTEDdebajo de las sábanas. Si ese es el caso, esta publicación explica que "net :: ERR_ABORTED está destinado a generarse solo cuando una acción del usuario hace que se interrumpa una carga. Esto puede suceder cuando una nueva navegación interrumpe una existente, o cuando el usuario hace clic en STOP botón."
John McCarthy
Gracias. En mi caso no es el usuario porque yo soy el usuario. La página tiene (también) muchos marcos. ¿Tal vez se cambia el marco src? Es extraño que nunca lo haya visto suceder en IE. Examinaré las redes internas.
styfle
@ nondescript1 Hice la captura mientras reproducía el error y lo volqué a un archivo. Ahora tengo un archivo json de 18,000 líneas. Que estoy buscando
styfle
3
Honestamente no lo se. En realidad, me encontré con su pregunta cuando estaba buscando más información sobre el estado = me cancelé, que es la razón por la que solo agrego comentarios y no una respuesta;). No tengo ninguna razón para pensar que esté relacionado con el almacenamiento en caché. Sospecho más de otra navegación iniciada por alguien en la página. Cuando vi esto, estaba intentando iniciar una descarga con window.open () que provocó la cancelación de otra solicitud del servidor. En mi caso, Firefox no tuvo este problema, pero Chrome sí.
John McCarthy
1
Solo para que no quede claro, una posible causa de "(cancelado)" en la columna de estado, aunque definitivamente no es la única causa posible, es que la URL como se indica ha devuelto un error 404 u otro error. Actualice forzosamente la URL en otra pestaña varias veces para asegurarse de que se carga de manera consistente.
rakslice

Respuestas:

592

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.

whamma
fuente
2
Muy informativo, gracias. Me cuesta mucho reproducir este error porque una vez que las cosas se almacenan en caché, no sucede. Si establezco un punto de interrupción en mi javascript, no sucede. Su primer punto probablemente no sea el problema porque no veo que se elimine un elemento. Sé con certeza que no es la viñeta 3. ¿Qué quiere decir con "Una vez que toca el contenido de un iframe, ya no puede cargar el recurso en él"? ¿Puede dar un ejemplo?
Styfle
1
Interesante. Así que necesito encontrar todas las document.writedirecciones de ese marco y asegurarme de que solo escriban cuando el marco está cargado. Marcaré esto como la respuesta correcta ya que usted respondió el significado de ese estado.
Styfle
3
@styfle Sí, pero también puede ser algo más que document.write. Cualquier cosa que intente escribir en el marco como appendChild o similar probablemente causará esto. Es posible que desee crear un controlador onLoad en cada cuadro que escriba trueen alguna variable, luego otros cuadros lo buscan primero antes de tocar cualquier cosa.
whamma
14
También he tenido problemas horribles con esto. Una cosa que he encontrado es que activa constantemente esto si la respuesta AJAX tiene un código de estado 301/302 y la URL de redireccionamiento está en otro dominio. Esta es una reproducción constante del problema para mí.
eb80
1
Para mí, el iframe se agrega al cuerpo y luego se elimina inmediatamente del cuerpo. Puse un salto de línea y el problema no estaba allí. Así que pon algo de tiempo de espera (15 ms) y supéralo. @whamma realmente motiva la forma en que abordó el problema. Gracias por tan grandes detalles en profundidad. :-)
muhammed basil
53

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>
fuco
fuente
3
Esto me salvó, fue el problema en mi caso donde utilicé angular's ng-clicken un botón type="submit"y luego hice algunas redes en la función llamada. Chrome siguió cancelando esa solicitud ...
Robin
1
Lamentablemente no me funciona. ¿Alguna otra pista?
Krzysztof Madej
¡Vaov también me salvó! Para un evento angular ng-click, había anidado las solicitudes de $ http y la segunda estaba siendo cancelada. Después de configurar la línea predeterminada de prevención, comenzó a funcionar nuevamente, gracias.
Bahadir Tasdemir
Gracias por esto. Sabía que no era CORS o un problema DOM. Tal vez @whamma podría actualizar su respuesta a incluir esto como posible causa de la integridad :)
glidester
¡Salve al señor! Señor, usted es un genio absoluto! ¡He sido salvado!
Dilnoor Singh
25

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

stianlp
fuente
Esta fue la causa principal para mí: un botón activó POST dos veces. No quería mover el botón fuera del elemento del formulario debido a las cosas de CSS, así que esta fue la solución: stackoverflow.com/questions/932653/…
Nikolai Koudelia
Mismo problema. Para aclarar, tenía un botón contenido en un formulario con un tipo de envío, pero tenía un clic que estaba haciendo un envío de formulario jquery, envío ajax. Funcionó en FF, pero falló en chome e IE, y me volvió loco hasta que lo encontré.
ChrisThompson
Esto soluciona un problema que me sucedió en una aplicación Vue.js donde un @clickevento estaba vinculado a un <button>elemento dentro de un contenedor de formularios. Evite hacer esto a menos que esté utilizando el @submit.preventmodificador de eventos de Vue .
Paul Wenzel
Este fue el caso para mí. Al agregar una type="button"etiqueta a mi botón, no se envió el formulario y se evitó el evento cancelado.
Brandon Medenwald
12

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.

James Kyburz
fuente
Exactamente lo que pasó. Encendí el complemento noscript y de repente iFrame ya no se cargaba.
Margus Pala
Para mí, fue el complemento Hola. Después de deshabilitar, las solicitudes ya no se cancelan.
Lenin Raj Rajasekaran
1
En mi caso, era la extensión de Chrome "Notificador de errores de JavaScript"
Alex
Intenté investigar todo y todavía no tuve suerte con Angular 8, deshabilité todas las extensiones y aún en la red 3G lenta, las llamadas anteriores se cancelan. :(
born2net
10

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.

Justin Cloud
fuente
Este fue exactamente mi problema. Este hilo tiene buenas respuestas sobre cómo solucionarlo: stackoverflow.com/questions/6666423/…
ToniTornado
8

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.

limodou
fuente
Encontrarse con el mismo problema. En mi caso, es un desarrollo local de WordPress / WooCommerce con el servidor invitado VirtualBox, y algunas solicitudes AJAX de WooCommerce tienen un tiempo de espera AJAX predefinido de 5000 ms. Si alguien tuvo el mismo problema, este tiempo de espera se definió en el includes/class-wc-frontend-scripts.phparchivo.
Ivan Shatsky
7

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

Jared Forsyth
fuente
Aunque es muy obvio en cuanto a la razón, pero aún así, esta es realmente una respuesta muy útil. Estaba editando un código antiguo de coffeescript, y había olvidado por completo que las comillas simples no hacían la #{}interpolación, por lo que la URL resultante tenía un formato incorrecto. Pero Chrome no me dijo nada al respecto.
kumarharsh
4

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/

William Budington
fuente
¿básicamente puede redirigir de un dominio sin certificado a uno certificado? de desnudo a www? o siempre ves cancelado o error de certificado?
Konstantin Vahrushev
3

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.

Phil M
fuente
Veo un comportamiento casi idéntico en Chrome 30 cuando uso los servicios de pago alojados en Datacash, pero en mi caso, la POST del sitio 3dsecure al sitio de Datacash se cancela, a pesar de que ambos son https. Está demostrando ser algo misterioso.
Jason
2

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

El guisante rojo
fuente
2

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ó.

Gerfried
fuente
2

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!

Tasnim Reza
fuente
2

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ó.

bestOfSong
fuente
2

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.

Daniel Kucal
fuente
1

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

gelviis
fuente
1

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.

Ali Sheikhpour
fuente
1

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({

     ...
    });

})
Denis Matafonov
fuente
0

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

Mario Gonzales Flores
fuente
0

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ó.

Nicolai Shestakov
fuente
0

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.

Jon P Smith
fuente
0

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.

NodeDad
fuente
0

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á

Hiresh
fuente
0

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.

FreeLightman
fuente
0

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.

Cameron
fuente
0

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

Nathan
fuente
0

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

Despertó
fuente
0

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.

Aleksandr Shumilov
fuente
0

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.

Vishal
fuente
0

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.

meol
fuente