З життя з Kubernetes: Як HTTP-сервер іспанців не шанував
Представник нашого клієнта, стек додатків якого мешкає у хмарі від Microsoft (Azure), звернувся з проблемою: з недавнього часу частина запитів деяких клієнтів із Європи почала завершуватися помилкою 400 (Неправильний запит). Всі програми написані на .NET, розгорнуті в Kubernetes.
Одна з програм - API, через який в кінцевому рахунку приходить весь трафік. Цей трафік слухає HTTP-сервер Кестрел, налаштований клієнтом .NET і розміщений у pod'і. З налагодженням нам пощастило тому, що був конкретний користувач, у якого стабільно відтворювалася проблема. Проте все ускладнювалося ланцюжком трафіку:
Здавалося б, тільки tcpdump допоможе у вирішенні цієї проблеми ... але повторю про ланцюжок трафіку:
розслідування
Очевидно, що послухати трафік краще на тому конкретному вузлі, Де Kubernetes розгорнув pod: об'єм дампа буде такий, що вийде досить швидко знайти хоч щось. І справді, при його розгляді було помічено такий кадр:
При уважному розгляді дампа було помічено слово M.laga. Легко здогадатися, що в Іспанії немає міста M.laga. Малага). Ухопившись за цю ідею, ми подивилися конфіги Ingress, де побачили вставлений місяць тому (за запитом клієнта) «нешкідливий» snippet:
Повернеться 400 Bad request - У лозі програми отримаємо вже знайому нам помилку:
{
"@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
}
Підсумки
Саме Kestrel не може коректно обробляти HTTP-заголовки з правильними символами UTF-8, які містяться в назвах досить великої кількості міст.
Додатковий фактор у нашому випадку – змінювати реалізацію Kestrel у додатку клієнт на даний момент не планує. Втім, issues в самому AspNetCore (№4318, №7707) говорять про те, що це і не допоможе.
Підсумовуючи: замітка більше не про специфічні проблеми Kestrel або UTF-8 (у 2019 році?!), А про те, що уважність та послідовне вивчення кожного кроку під час пошуку проблеми рано чи пізно дадуть свої плоди. Успіхів!