The site sends the tar.gz file saying it is gzip encoded. Firefox is likely handling this specially.

Yeah, I need to dig through the mozilla sources, but I'm guessing the fix here is going to be that if webkit/ephy is going to download the file rather than displaying it, then we don't want to decode it. Of course, you don't decide whether to display or download it until after seeing the headers, and by that point it's too late to call soup_message_disable_feature(), so we'll need some libsoup work either way.

(Actually, you probably don't decide for sure until after sniffing the file, which would happen after we'd already started ungzipping it... Hm... maybe it is just a special case for tar...)

(In reply to comment #2)
> (Actually, you probably don't decide for sure until after sniffing the file,
> which would happen after we'd already started ungzipping it... Hm... maybe it
> is just a special case for tar...)

Yeah... without having looked at the mozilla code yet, I think what we may end up doing is to disregard the Content-Encoding header (by disabling the soup feature in the message) based on the file name, assuming a false-positive by the server.

*** Bug 650360 has been marked as a duplicate of this bug. ***

void
nsHttpChannel::ClearBogusContentEncodingIfNeeded()
{
    // For .gz files, apache sends both a Content-Type: application/x-gzip
    // as well as Content-Encoding: gzip, which is completely wrong.  In
    // this case, we choose to ignore the rogue Content-Encoding header. We
    // must do this early on so as to prevent it from being seen up stream.
    // The same problem exists for Content-Encoding: compress in default
    // Apache installs.
    if (mResponseHead->HasHeaderValue(nsHttp::Content_Encoding, "gzip") && (
        mResponseHead->ContentType().EqualsLiteral(APPLICATION_GZIP) ||
        mResponseHead->ContentType().EqualsLiteral(APPLICATION_GZIP2) ||
        mResponseHead->ContentType().EqualsLiteral(APPLICATION_GZIP3))) {
        // clear the Content-Encoding header
        mResponseHead->ClearHeader(nsHttp::Content_Encoding);
    }
    else if (mResponseHead->HasHeaderValue(nsHttp::Content_Encoding, "compress") && (
             mResponseHead->ContentType().EqualsLiteral(APPLICATION_COMPRESS) ||
             mResponseHead->ContentType().EqualsLiteral(APPLICATION_COMPRESS2))) {
        // clear the Content-Encoding header
        mResponseHead->ClearHeader(nsHttp::Content_Encoding);
    }
}

fixed in master. might go into 3.0.2...