Highlights
Dos cambios esta semana afectan lo que devuelven sus requests. Los cuerpos de las responses dejan de llegar como mojibake en sitios que no son UTF-8, y las responses no-200 aceptadas por validate finalmente cuentan como éxito en lugar de fallo. También cerramos un par de brechas de seguridad en la API de clientes.
What's New
Non-UTF-8 pages return readable text on Single
Si llama a Single en foros búlgaros, comercio electrónico chino, noticias japonesas o cualquier cosa que envíe windows-1251, GBK, Big5 o Shift_JIS, el cuerpo de la response solía devolverse como bytes corruptos. La capa HTTP subyacente tenía un decodificador UTF-8 predefinido en el código, por lo que una página en cirílico llegaba como промоции y no había forma de recuperar el original por su parte.
Esto se solucionó en la capa de request. Single ahora detecta el charset de origen (a través del header Content-Type, luego <meta charset>, luego <meta http-equiv>) y lo transcodifica a UTF-8 antes de que el cuerpo llegue a su sobre JSON. Y las páginas UTF-8 o ASCII pasan sin cambios. El contenido binario como imágenes o PDFs nunca se decodifica. Si quiere los bytes sin procesar, returnBuffer: true todavía devuelve el buffer original.
Activo por defecto. Sin flags que activar. Las páginas que funcionaban antes siguen funcionando; las páginas que devolvían basura ahora devuelven texto legible. Los usuarios de navegadores tampoco tienen que pensar en esto; Chromium decodifica los charsets de forma nativa.
validate rules now drive success classification
Cuando configura validate en un request (por ejemplo, validate.status.accept = [200, 403]), el motor de requests ya respetaba su regla y resolvía la response sin errores. Pero nuestro clasificador de resultados upstream ignoraba su regla y agrupaba cualquier cosa que no fuera un 200 literal como application_fail. Dos consecuencias: su 403 aceptado aparecía como un fallo en el Dashboard, y dado que solo el éxito es facturable, esas responses entregadas tampoco se facturaban.
El clasificador ahora respeta lo que declaró validate. Los requests con validate se consideran un éxito siempre que el motor los haya resuelto sin errores, independientemente del status. Los requests sin validate se comportan igual que antes (éxito solo en 200), por lo que la ruta heredada no se ve afectada.
Corrección sin retroactividad: las filas históricas conservan su resultado almacenado, los nuevos requests se clasifican correctamente. Así que si ha estado viendo App Fail en responses que sabía que eran válidas, esta es la razón.
Security hardening on the customer API
Lanzamos la Wave 0 de una revisión de seguridad en toda la API de clientes:
- CORS ahora está restringido a
https://foura.ai. La configuración anterior reflejaba cualquier origen al enviar credenciales, que es la configuración estándar de CSRF. Las llamadas del navegador del mismo origen y sus llamadas a la API del lado del servidor no se ven afectadas. - La ruta de métricas detrás de su línea de tiempo de Activity solía aceptar un filtro
outcomede formato libre que iba directo a la consulta. Ahora está en una lista de permitidos con valores de outcome conocidos. No es explotable desde una cuenta normal, pero valía la pena cerrarlo.
Ninguno de los dos cambia ningún contrato de la API. No los notará durante el uso normal. Pero encontrar un problema y solucionarlo antes de que alguien se dé cuenta sigue mereciendo ser mencionado.
Activity labels match the Overview
Un detalle menor. La tabla de Activity en su Dashboard solía renderizar cadenas de outcome sin procesar como Application_fail, mientras que los chips de Overview, el gráfico de dona y la línea de tiempo mostraban etiquetas amigables (App Fail) y codificaban por colores cada outcome. Los mismos datos, dos presentaciones. Ahora están sincronizados, ambos leyendo de la misma etiqueta y mapa de colores, por lo que el status de una fila se ve igual dondequiera que lo consulte.
Numbers
Esta semana no trae nuevos números de latencia o de tasa de éxito. La mayor parte de esto es trabajo de corrección y seguridad donde la métrica correcta es "dejar de equivocarse" en lugar de "ir más rápido". El digest de la próxima semana debería tener datos de throughput de algunas cosas en curso.