Here's how I got to this question.
I'm using go1.12.1, and I'm doing a test that involves making a series of HTTP requests that set cookies, and use those cookies in subsequent requests. In this case, I'm using an
*httptest.Server (from
httptest.StartTLSServer(...)) to host the needed handlers and making real HTTP requests.
When you use any of the constructors to create an
*httptest.Server, the
(*httptest.Server).URL value has its host set to an IP and the port the server is listening on (as stated by
the docs).
I ran into a problem where some of the cookies in question have the
Domain attribute set to the host serving the HTTP handler. Because the host value is an IP and not a hostname,
*cookiejar.Jar does not send those cookies in requests (more info
here, if you're interested).
To get around that, I replaced the IP in
(*httptest.Server).URL with
localhost and attempted to connect using
(*httptest.Server).Client(), which trusts the cert being used by the *httptest.Server instance. That resulted in this error:
x509: certificate is valid for example.com, not localhost
If I do the extra leg work to create a self-signed cert that is valid for localhost and set up an *httptest.Server to use that, the cookie issue is resolved.
My question is: should everyone who wants/needs to use a TLS-enabled
*httptest.Server to test things the involve cookies with the
Domain attribute set be required to provide their own self-signed certs for
localhost? Is there a reason that the default TLS cert used by
httptest.StartTLSServer(...) doesn't include
localhost (but does include the IPv4 and IPv6 loopback addresses, as well as
example.com)?
I've attached a file showing tests of various permutations of attempting to use cookies with the Domain attribute through *httptest.Server. The test that I expected to pass is at line 174. The test showing that the original issue with cookies is resolved if I send requests to localhost with a cert valid for localhost is at line 185.