net/http: server links in crypto/tls when not serving TLS #30483
Comments
You can learn why with:
But I'm not sure this is a priority. Even if we did the games to make the linker happy enough to be able to drop things, that only helps the Server. We'd have to play the same games with the http.Transport code (as used by the http.Client) and basically you'd have to never use the http.Client or http.Transport types anywhere in your code, or ever import net/http/httputil.ReverseProxy (which uses Transport), etc, because the Transport doesn't know until runtime whether you're going to use https or not. Actually, considering the line above:
This is basically impossible to fix. Sorry. It's also been like this since day 1. |
I'm going to close this, as I don't see a way forward, and I also don't see why it matters in a world that's increasingly using (and often only using) https. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Build the following program:
What did you expect to see?
The resulting binary has no trace of crypto/tls in it, since it only ever serves unencrypted HTTP.
What did you see instead?
Note how the TLS library and its dependencies (I'm counting math/big) take at least 685.4 KB, almost 10% of the binary's size (#6853).
(The runtime looks huge mainly because of
runtime.pclntab
).bloatyconfig.txt:
The text was updated successfully, but these errors were encountered: