Destaques
Duas alterações esta semana afetam o que retorna das suas requests. Os bodies das responses deixam de chegar como mojibake em sites não-UTF-8, e as responses não-200 aceitas pelo validate finalmente contam como sucesso em vez de falha. Também corrigimos algumas brechas de segurança na API do cliente.
Novidades
Páginas não-UTF-8 retornam texto legível no Single
Se você chamar o Single em fóruns búlgaros, e-commerce chinês, notícias em japonês ou qualquer coisa que envie windows-1251, GBK, Big5 ou Shift_JIS, o body da response costumava retornar como bytes corrompidos. A camada HTTP subjacente usava um decodificador UTF-8 hard-coded, então uma página em cirílico chegava como промоции e não havia como recuperar o original do seu lado.
Isso foi corrigido na camada de request. O Single agora detecta o charset de origem (via header Content-Type, depois <meta charset> e depois <meta http-equiv>) e o transcodifica para UTF-8 antes que o body chegue ao seu envelope JSON. E páginas UTF-8 ou ASCII passam intactas. Conteúdo binário como imagens ou PDFs nunca é decodificado. Se você quiser os bytes brutos, returnBuffer: true ainda entrega o buffer original.
Ativo por padrão. Sem flags para ativar. Páginas que funcionavam antes continuam funcionando; páginas que retornavam lixo agora retornam texto legível. Usuários de navegadores também não precisam pensar nisso; o Chromium decodifica charsets nativamente.
Regras de validate agora direcionam a classificação de sucesso
Quando você define validate em uma request (por exemplo, validate.status.accept = [200, 403]), o motor de request já respeitava sua regra e resolvia a response sem erros. Mas nosso classificador de resultados upstream ignorava sua regra e categorizava qualquer coisa que não fosse um 200 literal como application_fail. Duas consequências: seu 403 aceito aparecia como falha no Dashboard e, como apenas o sucesso é faturável, essas responses entregues também não eram cobradas.
O classificador agora respeita o que o validate declarou. Requests com validate contam como sucesso sempre que o motor as resolveu sem erros, independentemente do status. Requests sem validate se comportam da mesma forma que antes (sucesso apenas em 200), de modo que o caminho legado permanece inalterado.
Correção apenas para o futuro: registros históricos mantêm seu resultado armazenado, novas requests são classificadas corretamente. Portanto, se você via App Fail em responses que sabia que eram válidas, o motivo era este.
Reforço de segurança na API do cliente
Lançamos a Wave 0 de uma revisão de segurança na API do cliente:
- CORS agora está restrito a
https://foura.ai. - A configuração anterior refletia qualquer origem ao enviar credenciais, que é a configuração padrão de CSRF. Chamadas de navegador de mesma origem (same-origin) e suas chamadas de API server-side não são afetadas.
- A rota de métricas por trás da sua linha do tempo de Activity costumava aceitar um filtro
outcomede formato livre que fluía diretamente para a query. Ela agora está limitada por uma allowlist a valores conhecidos de outcome. Não explorável a partir de uma conta normal, mas valia a pena fechar.
Nenhuma das alterações muda qualquer contrato de API. Você não as notará durante o uso normal. Mas encontrar um problema e corrigi-lo antes que alguém perceba ainda merece ser mencionado.
Labels de Activity correspondem ao Overview
Uma pequena melhoria. A tabela de Activity no seu Dashboard costumava renderizar strings de resultado brutas como Application_fail, enquanto os chips, o gráfico de rosca e a linha do tempo do Overview mostravam labels amigáveis (App Fail) e coloriam cada resultado. Mesmos dados, duas apresentações. Agora eles estão sincronizados, ambos lendo do mesmo mapa de cores e labels, para que o status de uma linha pareça o mesmo onde quer que você o verifique.
Números
Esta semana não traz novos números de latência ou taxa de sucesso. A maior parte disso é um trabalho de correção e segurança onde a métrica correta é "parar de errar" em vez de "ir mais rápido". O digest da próxima semana deve conter dados de throughput de algumas coisas em andamento.