ProHoster > Blog > administración > De la vida con Kubernetes: Cómo el servidor HTTP no favoreció a los españoles
De la vida con Kubernetes: Cómo el servidor HTTP no favoreció a los españoles
Un representante de nuestro cliente, cuya pila de aplicaciones reside en la nube de Microsoft (Azure), abordó un problema: recientemente, algunas solicitudes de algunos clientes de Europa comenzaron a terminar con el error 400 (Solicitud incorrecta). Todas las aplicaciones están escritas en .NET, implementadas en Kubernetes...
Una de las aplicaciones es la API, a través de la cual llega todo el tráfico. Este tráfico es escuchado por el servidor HTTP. Cernícalo, configurado por el cliente .NET y alojado en un pod. Con la depuración, tuvimos suerte en el sentido de que hubo un usuario específico que reprodujo constantemente el problema. Sin embargo, todo se complicó por la cadena de tráfico:
Parecería que sólo tcpdump ayudará a resolver este problema... pero repetiré sobre la cadena de tráfico:
Investigacion
Obviamente, es mejor escuchar el tráfico. en ese nodo específico, donde Kubernetes ha desplegado un pod: el volumen del volcado será tal que será posible encontrar al menos algo con bastante rapidez. Y efectivamente, al examinarlo, se notó el siguiente cuadro:
Tras una inspección más cercana del vertedero, se notó la palabra. M.laga. Es fácil adivinar que no existe la ciudad de Málaga en España (pero sí la hay). Málaga). Aprovechando esta idea, miramos las configuraciones de Ingress, donde vimos la insertada hace un mes (a pedido del cliente) fragmento "inofensivo":
Después de deshabilitar el reenvío de estos encabezados, ¡todo salió bien! (Pronto quedó claro que la aplicación en sí ya no necesitaba estos encabezados).
Ahora veamos el problema. más generalmente. Se puede reproducir fácilmente dentro de la aplicación realizando una solicitud de telnet a localhost:80:
regresará 400 Bad request — en el registro de la aplicación recibiremos un error que ya conocemos:
{
"@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
Específicamente cernícalo no puedo procese correctamente los encabezados HTTP con los caracteres correctos en UTF-8, que están contenidos en los nombres de una cantidad bastante grande de ciudades.
Un factor adicional en nuestro caso es que el cliente actualmente no planea cambiar la implementación de Kestrel en la aplicación. Sin embargo, los problemas en el propio AspNetCore (№ 4318, № 7707) dicen que esto no ayudará...
En resumen: la nota ya no trata sobre los problemas específicos de Kestrel o UTF-8 (¡¿en 2019?!), sino sobre el hecho de que Atención plena y estudio constante. Cada paso que dé mientras busca problemas, tarde o temprano dará frutos. ¡Buena suerte!