Bug Report
What is the issue?
Linkerd-proxy changes all HTTP headers to be lower cases. While the RFC states that header keys should be case insensitive, I think that linkerd-proxy should not modify the casing of the header names given the "no code change required" bit.
Note that header values are not modified and remain their original values.
How can it be reproduced?
- Start two deployments; one without linkerd and one with.
- Use
curl -sD - -o /dev/null http://<endpoint> to collect the response headers. I ran this from the host machine.
- Compare output with and without linkerd.
The same can also be done by spawning a shell in the pod and running the same command against the pod's IP or 127.0.0.1 vs a service that the pod runs behind.
Logs, error output, etc
$ k get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
non-linkerd-64499456d6-hf4zm 1/1 Running 0 3d9h 192.168.96.101 worker-01 <none> <none>
linkerd-757646fd4c-lrd4m 2/2 Running 0 3d1h 192.168.0.134 worker-01 <none> <none>
# with linkerd
curl -sD - -o /dev/null http://192.168.0.134
HTTP/1.1 200 OK
server: nginx
date: Sat, 01 Jun 2019 17:20:03 GMT
content-type: text/html
content-length: 6969
last-modified: Fri, 08 Mar 2019 19:14:12 GMT
accept-ranges: bytes
etag: "5c82bf04-1b39"
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
# without linkerd
curl -sD - -o /dev/null http://192.168.96.101
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 01 Jun 2019 17:20:18 GMT
Content-Type: text/html
Content-Length: 6969
Last-Modified: Fri, 08 Mar 2019 19:14:12 GMT
Connection: keep-alive
ETag: "5c82bf04-1b39"
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
linkerd check output
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-existence
-----------------
√ control plane namespace exists
√ controller pod is running
√ can initialize the client
√ can query the control plane API
linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ no invalid service profiles
linkerd-version
---------------
√ can determine the latest version
‼ cli is up-to-date
is running version 2.3.0 but the latest stable version is 2.3.1
see https://linkerd.io/checks/#l5d-version-cli for hints
control-plane-version
---------------------
‼ control plane is up-to-date
is running version 2.3.0 but the latest stable version is 2.3.1
see https://linkerd.io/checks/#l5d-version-control for hints
√ control plane and cli versions match
Status check results are √
Environment
- Kubernetes Version: 1.13.5
- Cluster Environment: (GKE, AKS, kops, ...) Kubespray
- Host OS: CentOS
- Linkerd version: 2.3.0
Possible solution
Additional context
I did not test if this also applies to request headers.
Bug Report
What is the issue?
Linkerd-proxy changes all HTTP headers to be lower cases. While the RFC states that header keys should be case insensitive, I think that linkerd-proxy should not modify the casing of the header names given the "no code change required" bit.
Note that header values are not modified and remain their original values.
How can it be reproduced?
curl -sD - -o /dev/null http://<endpoint>to collect the response headers. I ran this from the host machine.The same can also be done by spawning a shell in the pod and running the same command against the pod's IP or
127.0.0.1vs a service that the pod runs behind.Logs, error output, etc
linkerd checkoutputEnvironment
Possible solution
Additional context
I did not test if this also applies to request headers.