Posts for the month of April 2014

Why, Google, why?

Some things I cannot understand, no matter how hard I am trying.

Why on Earth, in Chrome when http[s] (standard, explicitly restart-able protocol) when a download of a 50+ Mb file fails at 98% (it knows the size and type of a content from headers) the damned thing removes file.crdownload? What prevents them to add a few likes like "if more than 50% completed then keep file and add option to restart.

What kind of stupidity it is? Following "Expire headers" which size that a content must be reloaded each time? Trying to minimize of idiot's confusion that file is of less size that it supposed to be - there is explicit .crdownload extension, to indicate that it is still in progress.

The only rational explanation is that such "feature" is sponsored by telecom operators, which is quite possible in a modern business..

OK, the more probable explanation, is that nowadays it is OK to reset a connection if server side considers it "too slow" - it is just an optimization technique - to serve fast [premium] connections fast, at the "compromise" of dropping the "losers". So, they simply don't restart connection in order not to interfere with site's "policy". But this is a crappy defaults. Why do they take site's side, not user's one?

Some narcissistic UX star might say "lets not clutter the interface to keep the illusion of simplicity". OK, fine, do restarts automatically for certain content-types, when you know the size of payload in headers and when connection is closed before file is retrieved.

The only answer it seems that everyone benefits if user restarts the download from the very beginning, because he would consume twice as much traffic, which everyone monetize. Otherwise I cannot understand why (wise and never evil =) Google cannot add a few lines of code to download manager.)