Compressed text attachments needlessly inaccessible on mobile browsers without extraction utility

[era]

Viewing attached DpkgTerminalLog.gz et al. attachments is cumbersome in many browsers, and impossible on many mobile devices. Launchpad could easily provide a link to something which decompresses compressed attachments and shows them as text/plain or similar.

[Deryck Hodge (deryck)]

I think this is more of a question for the LP Foundations team. They can certainly feel free to kick back to me if they don't think so. My reasoning is thinking that something like mod_gzip or mod_deflate would allow us to transparently do this. Maybe I'm completely wrong and those modules only serve plain text files as compressed.

At any rate, the Foundations team should be more qualified to respond to these type of questions and as to how possible doing something like this is for the librarian.

[Gary Poster (gary)]

I don't understand the term "applet" in the original request.

Whatever the mechanism, do I understand correctly that you would like attachments to essentially have a link to an uncompressed version if they are already compressed? I'm not sure on the feasibility of this, if so, but could investigate.

[era (era)]

Sorry, "applet" wasn't meant as a precise term. I changed the description. You got it nailed.

I was thinking along the same lines as Deryck; maybe this could be as simple as enabling an Apache plug-in. 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. I'm thinking maybe Launchpad could have a "View" and a "Download" link next to each attachment, sort of like many version control repository browsers do.

[Robert Collins (lifeless)]

What browsers is this cumbersome in? All browsers I know of handle
compressed files very nicely.

[era (era)]

Firefox on Ubuntu doesn't open the attachment directly, it offers to open in ... FileRoller I think? (See also bug #18995.) But I can cope with that; the real killer is being unable to triage what looks like an easy bug because the browser in my phone cannot open the attached log.

[Robert Collins (lifeless)]

On Sat, Oct 16, 2010 at 12:07 AM, era <email address hidden> wrote:
> Firefox on Ubuntu doesn't open the attachment directly, it offers to
> open in ... FileRoller I think?  (See also bug #18995.)  But I can cope
> with that; the real killer is being unable to triage what looks like an
> easy bug because the browser in my phone cannot open the attached log.

Which attachments in particular? This behaviour is influenced by many
things, compression (via several means) is just one of them.

[Gary Poster (gary)]

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.

[era (era)]

> Which attachments in particular?

What caused me to report this wishlist bug was DpkgTerminalLog.gz and VarLogDistupgradeTermlog.gz but it's hardly limited to that. This is sometimes plain text (DpkgTerminalLog.txt) and sometimes gzipped; I am unsure what controls this (Apport version?)

[Robert Collins (lifeless)]

@era its controlled by:
 - Content-Encoding
 - Content-Type
 - Content-Disposition
 - browser version
 - browser options

It is, sadly excrutiatingly painful.

What phone os/model & browser version are you using?

Are you accessing attachments on public or private bugs?

if its private bugs then this is deliberate: we send
content-disposition: attachment, and will continue to do so until we
deploy a new subsystem (which we are qaing at the moment).

On Tue, Oct 19, 2010 at 4:02 AM, Gary Poster <email address hidden> wrote:
> 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).

Yes, its all about browser versions + the headers I listed above.

> - 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.)

Some issues:
 - just-in-time compression is expensive
 - bandwidth is more expensive still
 - decompressing to recompress in apache/squid would be daft
 - we can use Vary *if* we believe that doing this is appropriate, and
control it from the librarian
 - but its really hard (is, for instance, a tar.gz a 'tar' + gzip CE
or a compressed-tar? If you claim the former, folk downloading it to
their disk will end up with .tar, not .tar.gz, and checksums get
damaged.

>  - Variation: We always send attachments uncompressed if the user's browser accepts gzip encoding (do all phone browsers?).

I could go on a bit, but I think the thing to do here is to treat this
as a very specific bug and analyse it in that context. Because
browsers *suck* in this area.

-Rob

[era (era)]

I think you are over-complicating things. All I want is to a way to view plain-text attachments even if they are gzipped when apport submits them. This is hardly controlled by what browser somebody ends up using to view them.