El historial y sus filtros

Dos funciones se confunden todo el tiempo. El historial es un registro: anota cada petición y respuesta que pasa, con la interceptación activada o no. La interceptación es una pausa: detiene la petición antes de que salga para que puedas verla o cambiarla, y el navegador queda esperando mientras tanto. Se puede trabajar casi todo el tiempo con la interceptación apagada y leer el historial después, con calma, sin que la aplicación se entere de que alguien la mira.

Las columnas del historial responden preguntas rápidas: el método dice si la petición pide o envía; el estado, cómo respondió el servidor (2xx bien, 3xx redirección, 4xx culpa del cliente, 5xx fallo del servidor); la longitud permite comparar respuestas de un vistazo; el tipo de contenido dice qué declara que es.

En la consola del laboratorio, la tabla historial tiene todas esas columnas. Empieza con SELECT * FROM historial y mira cuántas filas son de la aplicación y cuántas son ruido.

Filtrar por estado es el atajo más barato para encontrar dónde la aplicación se comportó distinto. Pero un error no vale lo mismo que otro. Un 404 de un icono que no existe es ruido. Un 403 es el control de acceso diciendo que no: bueno saberlo, no es un hallazgo. Un 500 es la aplicación fallando por dentro, normalmente porque recibió una entrada que no esperaba, y ahí sí hay algo que mirar: un error del servidor puede mostrar detalles internos o delatar una validación que falta.

La consulta SELECT n, ruta, estado FROM historial WHERE estado >= 400 devuelve los errores de la sesión.

Filtrar por método es otro corte útil: los POST, PUT y DELETE envían o cambian datos y suelen merecer más atención que los GET. Pero el corte por sí solo engaña: un POST no es interesante por serlo. En una página moderna, buena parte de los POST son medición de visitas de un tercero.

Consulta los POST con SELECT n, host, ruta FROM historial WHERE metodo = 'POST', cuenta las filas y fíjate en cuántas pertenecen a la aplicación y cuántas no.

Los filtros limpian la vista, y por eso hay que saber exactamente qué ocultan. El más habitual excluye imágenes, hojas de estilo y scripts. Reduce el historial de 24 a 16 filas en la consola y deja ver lo que importa. Pero el filtro decide por el tipo de contenido que la respuesta declara, no por lo que realmente contiene. Una respuesta mal etiquetada, o una ruta de la aplicación que sirve datos con un tipo inesperado, desaparecería junto con las imágenes.

La consulta del filtro por tipo de contenido está en la consola: SELECT n, host, ruta FROM historial WHERE mime NOT IN ('imagen', 'CSS', 'script').

Ordenar o agrupar por host da la fotografía de dónde se concentra el tráfico, y casi nunca coincide con dónde está lo importante. Un sitio de estáticos puede recibir la mitad de las peticiones sin que haya nada que probar en él. Saber cuántas peticiones recibe cada host ayuda a decidir qué se mira primero y qué se deja de lado.

Ejecuta SELECT host, COUNT(*) AS peticiones FROM historial GROUP BY host y busca el host con más peticiones.