Yup. I was under the impression that data transfer limits are a pretty American thing, and in Europe they're the hallmark of a shady, crap provider (most commonly a big telco).
It's true for all of Australia and getting worse each year as the ISPs fight for profits after the country reached market saturation on broadband connections.
In South Africa it's sometimes true. Capped copper internet is substantially cheaper (same price as uncapped in the US) and usually higher priority than uncapped. Wireless internet is prohibitively expensive, one such tab can easily deplete a data bundle.
However, even uncapped internet normally has a AUP (acceptable usage policy, also soft cap) that is usually around 200GB - exceed it and your internet is de-prioritized to the point of being almost useless.
Either way, 4GB favicons are probably unhealthy for the overall internet.
My originial unlimited iPhone 3g connection had abuse clauses. Nobody cared when I used tethering to download 20gigs of steam games overnight - but if I was perma torrenting they might have done.
The contractual limits give the company a legal out to deal with use that starts to impact other customers, they are not commonly enforced unless they are looking into a complaint to slow internet and your usage comes up as anomalous and potentially contributory (according to a friend at an ISP at least).
So glad that all Swiss providers, mobile as well as dsl, have no fair usage or capping for their unlimited plans.
Download or upload 2TB via torrent? - No one cares
A friend of mine who works at Swisscom (no. 1 provider here) said they were forced by their software to enter an upper limit, so they just entered the max allowed length of that integer number.
I got throttled to dialup speeds for a month in ~2007 by my UK ISP (Demon) for downloading over 60gb in a month. The small print mentioned an abuse clause but didn't specify what the actual automatic hard cutoff was. I was very pissed off at the time.
Looking back, the funniest thing about it was that I ended up having an argument with one of the support people on a broadband forum and they were arguing that only pirates would ever need more than 60gb and that internet TV was never going to take off because the BBC iPlayer trial hadn't worked well in their browser.
These days there are UK ISPs with their own 4K TV channels.
When you run out of memory something needs to be killed, or swapped. If you start swapping, you're not responsive anymore (you can generate data faster than writing it to disk). If you kill something, it may not be the application which needs to be killed.
Usually systems don't come preconfigured with a hard per-app limit (which is a bad thing...), or oom score (systemd got this more popular though), so crashing the OS is still fairly easy.
My experience is that the OOM killer is generally pretty good at picking the right process to kill. At least on linux, it also considers whether the process has child processes, and kills them preferentially. These two aspect together mean that a linux system should consistently kill the tab loading the favicon and not, say, x11.
Well, I did see an X11 server killed under unusual circumstances (not :0, but an Xvfb-for-Xpra; incidentally, this also killed its child, which was the offending process)
I have to ask: Why do favicons need the ability to be animated? It's like the ability to autoplay mp3s on a webpage upon loading: There may very well be a use case for it, but there's a pretty big use-case for it NOT being possible, which is that it's pretty goddamn stupid.
And since we're clearly not adhering to Unix philosophy on the web, I say that it being idiotic is a good enough reason to not allow for it.
One thing we need to figure out: how to ban assholes instead of banning features. In general, things can be either interesting XOR safe, and we're killing off more and more interesting things[0] on the web just because some assholes will surely make use of them.
> Why do favicons need the ability to be animated?
As favicons are animated in the tabs of some browsers I've seen it put to good use as a relatively unobtrusive attention grabber when a tab has new information.
A simple on/off is sufficient for this though, or if you want to be a bit more flashy a fade in/out, larger animations are somewhere between pointless and stupid so perhaps a size limit is in order (32Kb seems extravagant enough for me).
Notifications aren't (afaik) animated image files, but javascript manipulation of the dom to replace a small favicon with a new small favicon, on-demand
I've done non-animated ones myself using that method, but I've seen animated ones too - I assumed they were done by assigning an animated graphic rather than constantly updating the icon in a JS timer event until the notification is no longer relevant. Next time I see it I'll inspect the code and see what is going on.
...there is no way to tell the size of something you want to
download until you've downloaded it.
A HEAD request should give you the size of the response body, in octets, in the Content-Length response header. This should (almost) always be present from a well-behaved web server.
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.
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.
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.
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.
... with the notable exception of content prepared on the fly, e.g., bulk download of photo albums with some services such as Picasa or Dropbox; the reason being that the zip archive is being prepared in streaming and the server doesn't know its size.
This is a classic example of a DOS attack, the kind of thing 4chan'ers take delight in unleashing on unsuspecting visitors to a web page. Why do it? For the simple joy of screwing with people.
