Comment 7 for bug 659697

Thank you for the clarifications, era.

> I can see scenarios where it would be useful to get to download the compressed content as well, though, so I suppose it would be better to let the user choose somehow.

Right, that's what I was thinking. I might or might not be correct.

I see lots of options here. I think I will push this back to Deryck/Malone. Deryck/Jono/somebody will need to decide how to respond to this use case.

The core issue may be that we need to decide what phone browsers we support, and how well (not to entirely negate your Firefox example, but your "real killer" is the phone).

---

Above, I said "I see lots of options here." I started listing the options originally, but decided it was probably not particularly helpful, so I've shoved my draft off to a postscript of sorts here. I'm not even super clear on all of the sorts of files we stuff into the librarian and under what conditions, so these may be irrelevant. So, again, this is a postscript of options of how we could handle this.

- We send attachments uncompressed always, and hope that the browser accepts gzip encoding, and make sure we have this set up. (I doubt this will fly.)
  - Variation: We always send attachments uncompressed if the user's browser accepts gzip encoding (do all phone browsers?).
- We give different links for compressed/uncompressed.
  - Variation: We give links for compressed; and only give an uncompressed link if the uncompressed file is shorter than a max length, or a text mimetype and can be truncated to the max length. Sort of a "preview" thing--I can see this being nice generally.
- Nothing: attachments are too varied, and the win is too rare. We send what we've got.