...there is no way to tell the size of something you want to
download until you've downloaded it.
The way Go's built in HTTP libraries work is that, if you don't attach a Content-Length header yourself, you will automatically send a chunk-encoded response. That's exactly what the OP's server does, and as a result there is no Content-Length to look for.
User-Agents need to defend against this by setting an appropriate upper-limit on the size of the object they want to receive.
Note that there's another obvious way to try to consume bandwidth: host a "file download" that actually just sends a chunk-encoded random byte sequence until the connection closes.
Partial icon streams have no use to the client, and given the server should almost certainly have the entire icon in ram, streaming has no use for the server.
That all depends on the type of internet connection. Sure, it's a great idea for the first world where you get 1Gbps symmetrical for $70 a month. But not everyone has that good of a connection, and packets can be dropped like crazy, dramatically decreasing the size of the window.
Though, I suspect stestagg meant IP packet. Less than 1.5 kB is just too small for most icons. The ubiquitous 32×32 Wordpress icon is just about small enough, and still sharp enough for Retina, but Amazon’s more detailed favicon is 2.8 kB, Y-Combinator’s icon is 6.5 kB, Apple’s 2-toned logo is 9.1 kB, and Microsoft’s 4 colored squares are an astonishing 17.1 kB.
On the other hand, like everything else outdated about it, Slashdot’s icon is a mere 668 bytes.
I have just opened the page info for this reply page and am astonished to see a 256x256 image for the favicon. Who's utterly retarded idea was that?
I guess that answers my first question. "Idiotically large" is the answer.
Of course, there's nothing intrinsically bad about high-resolution favicons - esp. given the current ultra-high-res displays. The size difference is only most marked in this specific use-case.
"...In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred..." https://tools.ietf.org/html/rfc2616#section-14.13
If this were required, the keyword would have been "MUST be sent" - there are completely legitimate reasons for not returning Content-Length; this is noted directly in the RFC, as quoted above.