You don't change the content-type to reflect gzip compression being on
on the server. Gzip is a content-encoding and the browser should
seamlessly decode it. You do need to set the HTTP headers to tell the
browser is gzipped though, eg here's a gzip-encoded response example:
Request
Accept */*
Referer http://www.theage.com.au/
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us)
AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Response
Accept-Ranges bytes
Cache-Control max-age=3600, public, proxy-revalidate
Connection Keep-Alive
Content-Encoding gzip
Content-Length 1737
Content-Type application/x-javascript
Date Fri, 06 Mar 2009 22:37:15 GMT
Etag "17befe1-111d-775906c0"
Expires Fri, 06 Mar 2009 23:37:15 GMT
Keep-Alive timeout=2, max=100
Last-Modified Thu, 05 Mar 2009 07:53:39 GMT
P3p policyref="http://f2.com.au/w3c/p3p.xml";, CP="CAO DSP LAW CURa
ADMa DEVa TAIa PSAa PSDa IVAi IVDi OUR IND PHY ONL UNI PUR FIN COM NAV
INT DEM CNT PRE GOV"
Server Apache
Vary Accept-Encoding,User-Agent
On 07/03/2009, at 9:30 AM, David Adams wrote:
On Sat, Mar 7, 2009 at 9:24 AM, Maciek Sakrejda
<[email protected]> wrote:
> I think (some) people were asking about the back-end to try to
help you
> configure http compression, which is done differently with different
> servers.
Oh. Well, how nice for everyone that I went on at length about
completely unrelated details ;-)
On the server side, I've had to bolt on a compressor so all I'd really
like to know I suppose is what MIME type such files arrive with from
another server when everything is working. I've looked up the MIME
codes and am not trying to be lazy - I ended up with my files
automatically downloading, so I figured I'd ask other people what is
actually working for them.
Thanks!
