Z życia z Kubernetesem: Jak serwer HTTP nie sprzyjał Hiszpanom
Przedstawiciel naszego klienta, którego stos aplikacji znajduje się w chmurze Microsoft (Azure), zajął się problemem: w ostatnim czasie niektóre żądania od niektórych klientów z Europy zaczęły kończyć się błędem 400 (Zła prośba). Wszystkie aplikacje napisane w .NET, wdrożone w Kubernetesie...
Jedną z aplikacji jest API, przez które ostatecznie przechodzi cały ruch. Ten ruch jest nasłuchiwany przez serwer HTTP Pustułka, skonfigurowany przez klienta .NET i hostowany w zasobniku. W przypadku debugowania mieliśmy szczęście w tym sensie, że był konkretny użytkownik, który konsekwentnie powielał problem. Wszystko jednak komplikował łańcuch ruchu:
Wydawać by się mogło, że tylko tcpdump pomoże rozwiązać ten problem... ale powtórzę o łańcuchu ruchu:
Dochodzenie
Oczywiście lepiej jest słuchać ruchu ulicznego w tym konkretnym węźle, gdzie Kubernetes wdrożył poda: objętość zrzutu będzie taka, że przynajmniej coś będzie można znaleźć dość szybko. I rzeczywiście, badając go, zauważono następującą ramkę:
Po bliższym przyjrzeniu się wysypisku słowo to zostało zauważone M.laga. Łatwo się domyślić, że w Hiszpanii nie ma miasta M.laga (ale jest Malaga). Korzystając z tego pomysłu, przyjrzeliśmy się konfiguracjom Ingress, gdzie zobaczyliśmy tę wrzuconą miesiąc temu (na prośbę klienta) fragment „nieszkodliwy”.:
Wróci 400 Bad request — w logu aplikacji otrzymamy znany nam już błąd:
{
"@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
}
Wyniki
Konkretnie Pustułka nie mogę poprawnie przetwarza nagłówki HTTP z poprawnymi znakami w formacie UTF-8, które zawarte są w nazwach dość dużej liczby miast.
Dodatkowym czynnikiem w naszym przypadku jest to, że klient nie planuje obecnie zmian w implementacji Kestrel w aplikacji. Jednak problemy w samym AspNetCore (№ 4318, № 7707) mówią, że to nie pomoże...
Podsumowując: notatka nie dotyczy już konkretnych problemów Pustułki czy UTF-8 (w 2019?!), ale tego, że uważność i konsekwentna nauka Każdy krok w poszukiwaniu problemów prędzej czy później przyniesie owoce. Powodzenia!