来自 Kubernetes 的生活：HTTP 服务器为何不利于西班牙人

我们的客户代表（其应用程序堆栈驻留在 Microsoft 云 (Azure) 中）解决了一个问题：最近，来自欧洲的一些客户的一些请求开始以错误 400 结束（错误的请求）。 所有应用程序均用 .NET 编写，部署在 Kubernetes 中...

应用程序之一是 API，所有流量最终都通过它来。 此流量由 HTTP 服务器监听 红隼，由 .NET 客户端配置并托管在 Pod 中。 通过调试，我们很幸运，因为有一个特定的用户始终重现了该问题。 然而，流量链让一切变得复杂：

Ingress 中的错误如下所示：

{
   "number_fields":{
      "status":400,
      "request_time":0.001,
      "bytes_sent":465,
      "upstream_response_time":0,
      "upstream_retries":0,
      "bytes_received":2328
   },
   "stream":"stdout",
   "string_fields":{
      "ingress":"app",
      "protocol":"HTTP/1.1",
      "request_id":"f9ab8540407208a119463975afda90bc",
      "path":"/api/sign-in",
      "nginx_upstream_status":"400",
      "service":"app",
      "namespace":"production",
      "location":"/front",
      "scheme":"https",
      "method":"POST",
      "nginx_upstream_response_time":"0.000",
      "nginx_upstream_bytes_received":"120",
      "vhost":"api.app.example.com",
      "host":"api.app.example.com",
      "user":"",
      "address":"83.41.81.250",
      "nginx_upstream_addr":"10.240.0.110:80",
      "referrer":"https://api.app.example.com/auth/login?long_encrypted_header",
      "service_port":"http",
      "user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36",
      "time":"2019-03-06T18:29:16+00:00",
      "content_kind":"cache-headers-not-present",
      "request_query":""
   },
   "timestamp":"2019-03-06 18:29:16",
   "labels":{
      "app":"nginx",
      "pod-template-generation":"6",
      "controller-revision-hash":"1682636041"
   },
   "namespace":"kube-nginx-ingress",
   "nsec":6726612,
   "source":"kubernetes",
   "host":"k8s-node-55555-0",
   "pod_name":"nginx-v2hcb",
   "container_name":"nginx",
   "boolean_fields":{}
}

与此同时，Kestrel 给出了：

HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0

即使有最冗长的内容，Kestrel 错误也包含极其严重的内容。 有用的信息很少:

{
   "number_fields":{"ThreadId":76},
   "stream":"stdout",
   "string_fields":{
      "EventId":"{"Id"=>17, "Name"=>"ConnectionBadRequest"}",
      "SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
      "ConnectionId":"0HLL2VJSST5KV",
      "@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
      "@t":"2019-03-07T13:06:48.1449083Z",
      "@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()",
      "message":"Malformed request: invalid headers."
   },
   "timestamp":"2019-03-07 13:06:48",
   "labels":{
      "pod-template-hash":"2368795483",
      "service":"app"
   },
   "namespace":"production",
   "nsec":145341848,
   "source":"kubernetes",
   "host":"k8s-node-55555-1",
   "pod_name":"app-67bdcf98d7-mhktx",
   "container_name":"app",
   "boolean_fields":{}
}

似乎只有 tcpdump 才能帮助解决这个问题......但我会重复一下流量链：

调查

显然，最好听听交通情况 在该特定节点上，其中 Kubernetes 部署了一个 pod：转储量将使得至少可以很快找到一些东西。 事实上，在检查它时，注意到以下框架：

GET /back/user HTTP/1.1
Host: api.app.example.com
X-Request-ID: 27ceb14972da8c21a8f92904b3eff1e5
X-Real-IP: 83.41.81.250
X-Forwarded-For: 83.41.81.250
X-Forwarded-Host: api.app.example.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /front/back/user
X-Scheme: https
X-Original-Forwarded-For: 83.41.81.250
X-Nginx-Geo-Client-Country: Spain
X-Nginx-Geo-Client-City: M.laga
Accept-Encoding: gzip
CF-IPCountry: ES
CF-RAY: 4b345cfd1c4ac691-MAD
CF-Visitor: {"scheme":"https"}
pragma: no-cache
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36
referer: https://app.example.com/auth/login
accept-language: en-US,en;q=0.9,en-GB;q=0.8,pl;q=0.7
cookie: many_encrypted_cookies; .AspNetCore.Identity.Application=something_encrypted; 
CF-Connecting-IP: 83.41.81.250
True-Client-IP: 83.41.81.250
CDN-Loop: cloudflare

HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0

仔细检查垃圾场后，注意到了这个词 M.laga。 很容易猜到西班牙没有 M.laga 市（但有 马拉加）。 抓住这个想法，我们查看了 Ingress 配置，我们看到了一个月前插入的配置（应客户的要求） “无害”片段:

    ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header X-Nginx-Geo-Client-Country $geoip_country_name;
      proxy_set_header X-Nginx-Geo-Client-City $geoip_city;

禁用这些标头的转发后，一切都变得很好！ （很快就发现应用程序本身不再需要这些标头。）

现在我们来看看问题 更普遍。 通过向应用程序发出 telnet 请求，可以轻松地在应用程序内重现它 localhost:80:

GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Desiree

...返回 401 Unauthorized，正如预期的那样。 如果我们这样做会发生什么：

GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Désirée

?

将返回 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
}

结果

特别是红隼 不能 使用 UTF-8 中的正确字符正确处理 HTTP 标头，这些字符包含在相当多的城市名称中。

在我们的案例中，另一个因素是客户当前不打算更改应用程序中 Kestrel 的实现。 然而，AspNetCore 本身的问题（№4318, №7707）他们说这没有帮助......

总结一下：该说明不再是关于 Kestrel 或 UTF-8 的具体问题（2019 年？！），而是关于以下事实： 正念和持续的学习 你在寻找问题时所采取的每一步迟早都会取得成果。 祝你好运！

PS

另请阅读我们的博客：

• «Kubernetes 运行中的 6 个有趣的系统错误 [及其解决方案]“;
• «Kubernetes 提示和技巧：NGINX Ingress 中的自定义错误页面“;
• «Kubernetes Ingress 控制器概述和比较“;
• «监控 Kubernetes 节点之间的 ping - 我们的秘诀“;
• «关于 Linux 网络子系统的 3 个异常情况“。

来源： habr.com