There's at least one more downside: the user loses all indication of progress as the Content-Length is unknown when the headers are sent
dumply knows the exact size of each image as it is saved in the DB on upload, and all the zip byte headers are fixed, so the zip file size should be deterministic and calculable even before the first byte is sent. Remember we don't compress the already compressed images.
If you didn't know the file sizes, for example you had raw unknown input streams, or had compressible data, you can still guesstimate the content-length so the user got some progress bar, even if it wasn't 100% accurate.
Looks like using browser sniffing, you can deliver an exaggerated Content-Length to everyone but Opera and browsers will deal with it gracefully. Pretty neat. (Obviously not desirable for violating the HTTP spec, but the UX gains might be worth it.)
For example major mobile operators pipe HTTP connections through a proxy that recompresses images. In that case you see e.g. Safari's or Opera's UA string, but you're actually dealing with proxy's HTTP behavior.
An older article (2008) that also talks about misreporting content-length for fun and profit: http://tech.hickorywind.org/articles/2008/05/23/content-leng...
Are suggesting they would rather guess the browser by inference through presence of DOM properties and methods?
In the end it narrows down to: would you rather a) break the functionality for some users in exchange to give the best possible solution to others, or b) give an OK experience to everyone
I usually go with "b". I think that frustration is much more powerful than awe.
But yeah, it's probably indeterminate behavior.