On Mon, 2011-08-29 at 16:50 +0100, Colin Adams wrote:
> On 29 August 2011 16:45, Michael Snoyman wrote:
> "chunked" is the only valid transfer-encoding[1], while gzip
> must be
> specified on the content-encoding header[2]. For a simple
> example of
> these
Michael Snoyman wrote:
> > I think we should invert the logic of this (to avoid
> > double negatives) so we have:
> >
> > type ContentType = ByteString
> > decompress :: ContentType -> Bool
> >
> > browserDecompress = (/== "application/x-tar")
> > defaultDecompress = const True
>
On Tue, Aug 30, 2011 at 6:27 AM, Erik de Castro Lopo
wrote:
> Michael Snoyman wrote:
>
>> I'm wondering what the most appropriate way to handle this is.
>
> Just to get my thoughts in order I'll back track a little.
>
> In the HTTP repsonse, we have two header fields, content-type
> and content-en
Michael Snoyman wrote:
> I'm wondering what the most appropriate way to handle this is.
Just to get my thoughts in order I'll back track a little.
In the HTTP repsonse, we have two header fields, content-type
and content-encoding. For the later (which may be absent) we can
have encodings of gzip
On Aug 29, 2011 9:39 PM, "Michael Snoyman" wrote:
>
> On Mon, Aug 29, 2011 at 2:21 PM, Gregory Collins
> wrote:
> > On Mon, Aug 29, 2011 at 10:08 AM, Michael Snoyman
wrote:
> >> Hi all,
> >>
> >> Erik just opened an issue on Github[1] that affected me very recently
> >> as well when writing some
On Mon, Aug 29, 2011 at 4:28 PM, Herbert Valerio Riedel wrote:
> On Mon, 2011-08-29 at 13:21 +0200, Gregory Collins wrote:
>> A web server should not be setting "Content-encoding: gzip" on a
>> .tar.gz file.
>
> Why not? From RFC2616 compliant servers I'd expect a .tar.gz file to
> have the Conten
On Mon, Aug 29, 2011 at 5:28 PM, Herbert Valerio Riedel wrote:
> On Mon, 2011-08-29 at 13:21 +0200, Gregory Collins wrote:
>> A web server should not be setting "Content-encoding: gzip" on a
>> .tar.gz file.
>
> Why not? From RFC2616 compliant servers I'd expect a .tar.gz file to
> have the Conten
On Mon, 2011-08-29 at 13:21 +0200, Gregory Collins wrote:
> A web server should not be setting "Content-encoding: gzip" on a
> .tar.gz file.
Why not? From RFC2616 compliant servers I'd expect a .tar.gz file to
have the Content-* headers provide meta-information about the
content[1], e.g.
Content
On Mon, Aug 29, 2011 at 2:21 PM, Gregory Collins
wrote:
> On Mon, Aug 29, 2011 at 10:08 AM, Michael Snoyman wrote:
>> Hi all,
>>
>> Erik just opened an issue on Github[1] that affected me very recently
>> as well when writing some automated Hackage checking code[2]. The
>> issue is that http-enum
On Mon, Aug 29, 2011 at 10:08 AM, Michael Snoyman wrote:
> Hi all,
>
> Erik just opened an issue on Github[1] that affected me very recently
> as well when writing some automated Hackage checking code[2]. The
> issue is that http-enumerator sees the content-encoding header and
> decompresses the t
Brandon Allbery wrote:
> On Mon, Aug 29, 2011 at 04:08, Michael Snoyman wrote:
>
> > So one possible solution is to just add an option to never decompress
> > response bodies, but that's a bit of a hack. The real question is:
> > what's the correct way to handle these tarballs? Web browsers seem
On Mon, Aug 29, 2011 at 04:08, Michael Snoyman wrote:
> So one possible solution is to just add an option to never decompress
> response bodies, but that's a bit of a hack. The real question is:
> what's the correct way to handle these tarballs? Web browsers seem to
> know not to decompress them,
Hi all,
Erik just opened an issue on Github[1] that affected me very recently
as well when writing some automated Hackage checking code[2]. The
issue is that http-enumerator sees the content-encoding header and
decompresses the tarball, returning an uncompressed tarfile. I can
avoid this with rawB
13 matches
Mail list logo
