Hacker News Reader

Comment by Lukasa | Hacker News Reader

Only if the file is served as one large chunk. If sent using Transfer-Encoding: chunked, there is no requirement to provide a Content-Length header, and a HEAD request may not show one.

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.

View on HN

A favicon should probably never be chunked in the first place.

Why?

The body for the majority of favicons should fit into a single tcp packet. Adding the overhead of chunking is completely pointless.

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.

> The body for the majority of favicons should fit into a single tcp packet.

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.

Still not a hot idea. The IP packet size is ultimately limited by the Ethernet frame size, which is 1500 bytes practically everywhere. The article says, “A ton of favicon were bigger than 50k,” so it would take over 30 flawlessly delivered fragments to create this hypothetical “single” TCP segment. Any congestion anywhere between you and the server, and the segment does not succeed.

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.

How the hell big are these icons? 16x16 pixels uncompressed RGB is 768 bytes (1024 if you're using padding or alpha).

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.

Guess whose. (Starts with A, ends with -pple. Actually, that's not true either - .ICO has historically supported 256x256x16b for decades: there just wasn't anyone making them.)

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.

Reply on news.ycombinator.com