Starting from etcd v3.5.0, etcd client v3 sends invalid :authority header field value which violates RFC.

Suppose we created a client like so:

        c, err := clientv3.New(clientv3.Config{
                Endpoints: []string{
                        "https://example.com:2379",
                },
                ...
        }  

And started making a connection and tried to get some stuff from etcd server.

In the previous etcd client v3, it sends :authority header field value like this:

example.com:2379

But now with the v3.5.0, it sends like this:

#initially=[https://example.com:2379]

According to the RFC7540, :authority header field contains the authority portion of the target URI.
RFC3986 dictates that authority is:

authority   = [ userinfo "@" ] host [ ":" port ]
host        = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
reg-name    = *( unreserved / pct-encoded / sub-delims )
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

#initially=[https://example.com:2379] is not a valid authority.

It seems to me that there might be a bug in the code that authority is not parsed or extracted correctly.
The annoying fact of this issue is that it works if server does not validate the invalid field value. But if you have a proxy between client and server which checks some non-compliant octets, then proxy refuses a request.