[icedtea-web] RFC: Fix caching of compressed content

[Omair Majid]

Hi,

* Andrew Azores <aazores at redhat.com> [2014-05-02 16:58]:
> On 05/02/2014 04:32 PM, Omair Majid wrote:
> >It was brought to my attention that icedtea-web was re-downloading the
> >jars (which should have been cached) on subsequent runs of a jnlp
> >application. I dug into it and found a real bug.
> >
> >To decide if an item is cached, icedtea-web does a HEAD request and
> >compares the Content-Length with the size of the file. This works fine
> >when the jars were not compressed. When the jars are fetched compressed
> >and then uncompressed on disk, there is a mismatch between the sizes and
> >icedtea-web decides the content is not cached.
> >
> >The attached patch stores the compressed size in the cache info file and
> >uses that instead of the actual file size in the size-comparison.
> 
> Can there be a reproducer for this?

This is not a functional change (at least, I really hope it isn't). It's
a performance change. I am not sure how to write a reproducer that
checks for startup speed. Any suggestions?

> Or is there already an existing one?

The test case that I used for this is a production server that's
internal, sadly.

> Manually testing looks good though, nothing appears broken and
> applets (eg Elluminate) don't appear to be redownloading, according
> to the progress bar which just jumps from 0 to 100.

Yeah, that 0 to 100 jump means that the cache is working correctly. Were
any of these test cases re-downloading before?

> The delay before
> this happens is just the overhead from establishing a connection and
> waiting for the result of the HEAD request(s), right?

Yes. This delay should be very small (I measured 0 seconds on many
lookups) but can be as large as ~10 seconds. See my other patch for a
timeout implementation that improves this too.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681