Streaming exec/attach fails with kubelet 1.36.x: relative BaseURL (no scheme) misinterpreted as HTTPS

[Maksim-Siniugin]

What happened?

kubectl exec/kubectl run -it/kubectl attach fail against pods when using
cri-dockerd as the CRI shim with kubelet/kubectl v1.36.2. The kubelet proxies
the exec/attach request to the address cri-dockerd's streaming server returns,
but errors out because the client attempts a TLS handshake against a plain
HTTP server:

warning: couldn't attach to pod/tlsdbg, falling back to streaming logs: Internal error occurred: error sending request: Post "//127.0.0.1:35417/cri/attach/WwJa7gGv": http: server gave HTTP response to HTTPS client

Note the URL has no scheme (//127.0.0.1:35417/...), which matches the
comment in cmd/server.go:

https://github.com/Mirantis/cri-dockerd/blob/master/cmd/server.go#L186-L194

// Initialize streaming configuration. (Not using TLS now)
streamingConfig := &streaming.Config{
    // Use a relative redirect (no scheme or host).
    BaseURL: &url.URL{Path: "/cri/"},
    Addr:    resolvedAddr,
    ...

Isolating the cause

• crictl --runtime-endpoint unix:///run/cri-dockerd.sock exec -it <id> sh
  works fine — cri-dockerd's own streaming server is healthy and reachable.
• The failure only happens when the request goes through kubelet's
  exec/attach proxy path (kubectl exec/run -it/attach).
• Ruled out: kube-proxy / NodePort-vs-ephemeral-port overlap (reproduced on a
  cluster with no kube-proxy, Antrea in proxyAll mode); explicit
  --streaming-bind-addr=127.0.0.1 (no effect, same error, just a different
  loopback port).
• Same exact Kubernetes/Docker/cri-dockerd version combo previously worked
  fine on another cluster; only relevant delta found across many rounds of
  debugging.

Fix that resolves it

Explicitly setting Scheme and Host on BaseURL instead of leaving it as a
scheme-less relative URL fixes the issue completely:

streamingConfig := &streaming.Config{
    BaseURL: &url.URL{
        Scheme: "http",
        Host:   resolvedAddr,
        Path:   "/cri/",
    },
    Addr: resolvedAddr,
    ...

Built and deployed this patch and kubectl exec -it / kubectl run -it work
correctly again.

Environment

• cri-dockerd version: 0.4.4
• Docker version: 29.6.2
• kubelet/kubectl version: 1.36.2
• CNI: Antrea (reproduced both with kube-proxy and with kube-proxy disabled +
  Antrea proxyAll)
• OS: Arch Linux, kernel 7.1.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jul 2026 17:30:57 +0000 x86_64 GNU/Linux

Expected behavior

kubectl exec -it/kubectl run -it/kubectl attach should work normally
with the default (unpatched) cri-dockerd configuration.

Additional context

This looks like a compatibility regression between newer kubelet's
exec/attach proxy handling (k8s.io/apimachinery/pkg/util/proxy.UpgradeAwareHandler)
and cri-dockerd's intentionally scheme-less "relative redirect" BaseURL. A
similar symptom (identical error string, same log line format) was reported
independently for k3s's embedded docker/cri shim on Docker 29.4.1:
k3s-io/k3s#14017

[dje4om]

Hi,

same issue here with this environment:

• cri-dockerd 0.3.26
• docker 28.0.4 from flatcar os "stable" 4593.2.2
• kubelet 1.36.3
• cni calico (kube-proxy) or cilium (without kube-proxy)

k3s made a fix on their cri-dockerd fork :

• issue: kubectl exec on pod is returning error on exec when docker: true k3s-io/k3s#14017
• pr: [Release-1.36] Fix kubectl exec when using docker k3s-io/k3s#14021
• commit: k3s-io@48e0747

[dje4om]

We found that this issue is reproductible with kubectl >= 1.30.0, sounds obvious to use the right kubectl client, but could be useful as an information
We had a feedback from a user who used a pretty old kubectl client (v1.29.2) and said us it worked for him
As a temporary workaround, it is possible to kubectl exec on already upgraded cluster with a =< 1.29.12 kubectl client version

[MamyAKKK]

I encountered the same problem:

• docker : 29.5.3
• kubelet : 1.36.2
• cri-dockerd : 0.4.4.3
• cni : v1.9.1
• calico : v3.32.1

---

cmd:
kubectl exec -it <pod> -- /bin/sh

---

error message :
error: Internal error occurred: error sending request: Post "//[::]:34221/cri/exec/Z_q2k_vz": http: server gave HTTP response to HTTPS client

---

Are there any optimization methods? thx~

[tmsdce]

Same issue here. As @Maksim-Siniugin pointed out, k3s had a similar issue too. They patched their fork simply by dropping the BaseURL : k3s-io@48e0747

Just tested it out and it works.

This bug is blocking us from upgrading to 1.36. It would be great if a maintainer could give us some visibility on this issue (@awmirantis maybe?)

[MamyAKKK]

Same issue here. As @Maksim-Siniugin pointed out, k3s had a similar issue too. They patched their fork simply by dropping the BaseURL : k3s-io@48e0747

Just tested it out and it works.

This bug is blocking us from upgrading to 1.36. It would be great if a maintainer could give us some visibility on this issue (@awmirantis maybe?)

If possible, you can consider switching to k8s+containerd. This configuration is not affected by the cri-dockerd plugin and can be upgraded to the latest version. That's what I'm currently doing.
Of course, the Docker system is still quite convenient to use, especially for platforms that have been around for a while~ ^_^/

[tmsdce]

@MamyAKKK Agreed. This is the way to go for new clusters (which I also do). But when it comes to switching existing clusters in-place, it is not that simple as that involves manual steps that does not scale well when you're managing many clusters.

[hernando-garcia]

same problem encountered:

• docker-ce 29.7.2
• cri-dockerd 0.4.4
• k8s upstream v1.36.2

kubectl exec -it -n sysops nginx-deployment-to-smoke-test-k8s-for-tstharu102-7d96944bncbdk -- bash
error: Internal error occurred: error sending request: Post "//[::]:35557/cri/exec/twbdWbNu": http: server gave HTTP response to HTTPS client

The following fix it:

@@ -185,7 +185,7 @@ func RunCriDockerd(f *options.DockerCRIFlags, stopCh <-chan struct{}) error {
        // Initialize streaming configuration. (Not using TLS now)
        streamingConfig := &streaming.Config{
                // Use a relative redirect (no scheme or host).
              - BaseURL:                         &url.URL{Path: "/cri/"},
              + BaseURL:                         &url.URL{Scheme: "http", Path: "/cri/"},
                Addr:                            resolvedAddr,
                StreamIdleTimeout:               r.StreamingConnectionIdleTimeout.Duration,
                StreamCreationTimeout:           streaming.DefaultConfig.StreamCreationTimeout

The initial results of testing it suggests it is working:

 kubectl exec -it -n sysops nginx-deployment-to-smoke-test-k8s-for-tstharu102-7d96944bnfjbc -- bash
[root@nginx-deployment-to-smoke-test-k8s-for-tstharu102-7d96944bnfjbc /]#

[shiranzby]

I can reproduce the same issue on an Ubuntu-based kubeadm cluster.

Environment:

• OS: Ubuntu Server 26.04.1 LTS
• Architecture: amd64
• Kubernetes: v1.36.4
• Docker Engine: 29.7.2
• cri-dockerd: 0.4.4
• CNI: Calico 3.32.2

All three nodes are Ready, Calico and CoreDNS are Running, and the test Pod starts successfully:

pod/dns-test condition met

However, kubectl exec fails with:

error: Internal error occurred: error sending request:
Post "//[::]:46039/cri/exec/...":
http: server gave HTTP response to HTTPS client

The Pod itself is healthy. I was able to verify CoreDNS successfully by running nslookup as the container's main command and reading the result with kubectl logs, so this appears to affect only the exec/attach streaming path.

I also tested with the host proxy disabled and obtained the same result, so the error does not appear to be caused by HTTP_PROXY/HTTPS_PROXY.

The environment is very similar to the other Docker 29.7.2 and cri-dockerd 0.4.4 reproduction reported in this thread, except this cluster uses Ubuntu 26.04.1, Kubernetes v1.36.4, and Calico 3.32.2.