Problem is application user code access to gzip encoded content is inconsistent:
- The first time, the content returned by HttpURLConnection is still gzipped.
- Subsequent accesses, applet code would see unzipped content, yet the response header still shows content-encoding as "gzip".
The cause was a late unzip on the downloaded temporary file when saving it to cache. It also does not update the header field value after the uncompression.
1. If user-code request has accept-encoding gzip or pack200-gzip, do not decompress. This is based on thread local boolean on DeployCacheHandler. We set this flag when setting accept-content: gzip, pack200-gzip.
2. Check for accept-encoding before set request header, if already has accept-encoding for gzip or pack200-gzip do not add and remember to not decompress.
3. Adjust content-length and content-encoding accordingly.
* Fixed with changeset: