<p><br>
On Aug 29, 2011 9:39 PM, "Michael Snoyman" <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
><br>
> On Mon, Aug 29, 2011 at 2:21 PM, Gregory Collins<br>
> <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>> wrote:<br>
> > On Mon, Aug 29, 2011 at 10:08 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
> >> Hi all,<br>
> >><br>
> >> Erik just opened an issue on Github[1] that affected me very recently<br>
> >> as well when writing some automated Hackage checking code[2]. The<br>
> >> issue is that http-enumerator sees the content-encoding header and<br>
> >> decompresses the tarball, returning an uncompressed tarfile. I can<br>
> >> avoid this with rawBody = False, but that's not a real solution, since<br>
> >> that also disables chunked response handling.<br>
> ><br>
> > A web server should not be setting "Content-encoding: gzip" on a<br>
> > .tar.gz file. I agree that http-enumerator is correctly following the<br>
> > spec by decompressing.<br>
> ><br>
> > If you decide to implement a workaround for this, the only reasonable<br>
> > thing I can think of is adding a "ignoreContentEncoding" knob the user<br>
> > can twiddle to violate spec.<br>
><br>
> I'm wondering what the most appropriate way to handle this is. Maybe a<br>
> dontDecompress record, looking like:<br>
><br>
> type ContentType = ByteString<br>
> dontDecompress :: ContentType -> Bool<br>
><br>
> Then browser behavior would be:<br>
><br>
> browserDecompress = (== "application/x-tar")<br>
><br>
> and current behavior would be:<br>
><br>
> defaultDecompress = const False<br>
><br>
> I don't have any strong opinions here...<br>
></p>
<p>I agree with Gregory's suggestion of an API that allows an application to see the data prior to decoding the Content-Encoding. It could be tagged with the name of the content-coding, and there could be a generic decode function (ie. the library already knows what needs to be done to decode, so there's no need for the application to go looking up the decode function by name).</p>
<p>Conrad.</p>