litespeed serving index.html.gz incorrectly (re-compressed?)

[aww]

On a new install where wp-super-cache is trying to serve it's own pre-compressed files, litespeed seems to be sending them as binary when apache gets it right.

Perhaps I need to exclude recompressing them somehow?

Works fine in apache, litepspeed serves garbled (looks like native gzip)

Headers are almost indentical.

litespeed

Originally Posted by litespeed

HTTP/1.1 200 OK
Content-Encoding: gzip
Vary: Accept-Encoding, Accept-Encoding, Cookie
Date: Fri, 23 Dec 2011 09:07:02 GMT
Server: LiteSpeed
Accept-Ranges: bytes
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "2483-4ef43dba-0"
Last-Modified: Fri, 23 Dec 2011 08:37:14 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 9370
Cache-Control: max-age=3, must-revalidate

apache

Originally Posted by apache

HTTP/1.1 200 OK
Date: Fri, 23 Dec 2011 09:06:22 GMT
Last-Modified: Fri, 23 Dec 2011 08:37:14 GMT
Accept-Ranges: bytes
Content-Length: 9347
Cache-Control: max-age=3, must-revalidate
Expires: Fri, 23 Dec 2011 09:06:25 GMT
Vary: Accept-Encoding,Cookie
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip

So the content type is the same and the critical content-encoding is there.

But my guess is that litespeed sees text/html content-type and tries to re-encode it with gzip because the filetype (html.gz) is not excluded. Length is slightly longer which also hints at re-compression with just a repeated compression header.

But I do not know how to exclude by extension, litespeed only supports mime-type?

Is there any possible easy workaround?

I know one solution is just to let litespeed make the gzip in it's own area but client wants apache backwards compatibility.