Comment 8 for bug 1103136

Digging deeper, I think the issue here is the combination of 'gzip' and 'Range'. When handing out a Range request, we truncate the body after the requested range has been satisfied. The problem is that this truncation ends up chopping off the gzip trailer from the transformed data (which is stored in zlib format, then transformed to gzip upon request).

As far as I can tell, the 'unexpected EOF' comes from the gzip.NewReader that wraps the response body choking when it doesn't find the gzip trailer, around http://golang.org/src/pkg/compress/flate/inflate.go#L637 apparently.

I'll confirm with the in-house golang experts, but seems like we have a bug on the U1 side, which can be temporarily be worked around by using Content-Encoding: deflate (which won't transform the stream) or Content-Encoding: identity which will uncompress the stream instead.