Da vida con Kubernetes: Como o servidor HTTP non favorecía aos españois
Un representante do noso cliente, cuxa pila de aplicacións reside na nube de Microsoft (Azure), abordou un problema: recentemente, algunhas solicitudes dalgúns clientes de Europa comezaron a rematar co erro 400 (Solicitude incorrecta). Todas as aplicacións están escritas en .NET, despregadas en Kubernetes...
Unha das aplicacións é a API, a través da cal chega finalmente todo o tráfico. Este tráfico é escoitado polo servidor HTTP Xurelo, configurado polo cliente .NET e aloxado nun pod. Coa depuración, tivemos sorte no sentido de que había un usuario específico que reproducía constantemente o problema. Non obstante, todo foi complicado pola cadea de tráfico:
Parece que só tcpdump axudará a resolver este problema... pero repetirei sobre a cadea de tráfico:
Investigación
Obviamente, é mellor escoitar o tráfico nese nodo específico, onde Kubernetes despregou un pod: o volume do vertedoiro será tal que será posible atopar polo menos algo bastante rápido. E de feito, ao examinalo, notouse o seguinte cadro:
Tras unha inspección máis atenta do vertedoiro, notouse a palabra M.laga. É doado adiviñar que non hai cidade de M.laga en España (pero si Málaga). Aproveitando esta idea, miramos as configuracións de Ingress, onde vimos a inserida hai un mes (a petición do cliente) fragmento "inofensivo".:
Volverá 400 Bad request — no rexistro da aplicación recibiremos un erro que xa nos é familiar:
{
"@t":"2019-03-31T12:59:54.3746446Z",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"ConnectionId":"0HLLLR1J974L9",
"message":"Malformed request: invalid headers.",
"EventId":{
"Id":17,
"Name":"ConnectionBadRequest"
},
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ThreadId":71
}
Resultados de
En concreto Kestrel non podo procesar correctamente as cabeceiras HTTP cos caracteres correctos en UTF-8, que están contidos nos nomes dun número bastante grande de cidades.
Un factor adicional no noso caso é que o cliente non planea cambiar actualmente a implementación de Kestrel na aplicación. Non obstante, os problemas no propio AspNetCore (№ 4318, № 7707) din que isto non vai axudar...
Para resumir: a nota xa non trata sobre os problemas específicos de Kestrel ou UTF-8 (en 2019?!), senón sobre o feito de que atención plena e estudo coherente Cada paso que deas mentres buscas problemas tarde ou cedo dará os seus froitos. Moita sorte!