ProHoster > blog > amministrazione > Dalla vita con Kubernetes: come il server HTTP non ha favorito gli spagnoli
Dalla vita con Kubernetes: come il server HTTP non ha favorito gli spagnoli
Un rappresentante del nostro cliente, il cui stack di applicazioni risiede nel cloud Microsoft (Azure), ha affrontato un problema: recentemente, alcune richieste di alcuni clienti dall'Europa hanno iniziato a terminare con l'errore 400 (Richiesta non valida). Tutte le applicazioni sono scritte in .NET, distribuite in Kubernetes...
Una delle applicazioni è l'API, attraverso la quale alla fine arriva tutto il traffico. Questo traffico viene ascoltato dal server HTTP Gheppio, configurato dal client .NET e ospitato in un pod. Con il debug siamo stati fortunati nel senso che c'era un utente specifico che riproduceva costantemente il problema. Tuttavia, tutto è stato complicato dalla catena del traffico:
Sembrerebbe che solo tcpdump possa aiutare a risolvere questo problema... ma lo ripeterò per quanto riguarda la catena del traffico:
indagine
Ovviamente è meglio ascoltare il traffico su quello specifico nodo, dove Kubernetes ha implementato un pod: il volume del dump sarà tale che sarà possibile trovare almeno qualcosa abbastanza rapidamente. E infatti, esaminandolo, è stato notato il seguente frame:
Dopo un'ispezione più attenta della discarica, la parola è stata notata M.laga. È facile intuire che non esiste una città di M.laga in Spagna (ma c’è Malaga). Cogliendo questa idea, abbiamo guardato le configurazioni di Ingress, dove abbiamo visto quella inserita un mese fa (su richiesta del cliente) frammento "innocuo".:
Dopo aver disabilitato l'inoltro di queste intestazioni, tutto è andato bene! (Divenne presto chiaro che l'applicazione stessa non aveva più bisogno di queste intestazioni.)
Ora esaminiamo il problema più generalmente. Può essere facilmente riprodotto all'interno dell'applicazione effettuando una richiesta telnet a localhost:80:
Sarà di ritorno 400 Bad request — nel registro dell'applicazione riceveremo un errore che ci è già familiare:
{
"@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
}
Risultati di
Nello specifico Gheppio non si può elaborare correttamente le intestazioni HTTP con i caratteri corretti in UTF-8, che sono contenute nei nomi di un numero abbastanza elevato di città.
Un ulteriore fattore nel nostro caso è che il cliente attualmente non prevede di modificare l'implementazione di Kestrel nell'applicazione. Tuttavia, i problemi nello stesso AspNetCore (№ 4318, № 7707) dicono che questo non aiuterà...
Riassumendo: la nota non riguarda più i problemi specifici di Kestrel o UTF-8 (nel 2019?!), ma il fatto che consapevolezza e studio coerente Ogni passo che fai durante la ricerca dei problemi prima o poi darà i suoi frutti. Buona fortuna!