Header viewers show different things.

Cacheability engine, delorie, etc. show it different.

[ianevans]

I added a gzip function to a test page at:
snip. The function gzips the output, sends the correct content length headers, etc.

When I run it through the header viewer at leknor.com it shows a full set of headers:

HTTP/1.1 200 OK
Date Wed, 06 Aug 2003 06:59:10 GMT
Server Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.26 FrontPage/5.0.2.2623 AuthMySQL/2.20
X-Powered-By PHP/4.0.6
Content-Encoding gzip
Vary Accept-Encoding
Content-Length 90
X-Content-Encoded-By class.gzip_encode 0.67
Connection close
Content-Type text/html

Neither delorie or swain show the Content-Length header:

HTTP/1.1 200 OK
Date: Wed, 06 Aug 2003 07:05:14 GMT
Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.26 FrontPage/5.0.2.2623 AuthMySQL/2.20
X-Powered-By: PHP/4.0.6
Connection: close
Content-Type: text/html

And because it's not seeing the content length, etc, the cacheability engine (www.ircache.net/cgi-bin/cacheability) gives me a failing grade for HTTP/1.0 persistent connections.

Any reason why I'm getting such varied results? Obviously leknor's seeing the headers so they're being sent. Is it just a problem with the code of the cacheability engine?

[edited by: DaveAtIFG at 11:10 am (utc) on Aug. 6, 2003]
[edit reason] No specifics please [/edit]

[Dreamquick]

I tried a raw request using netcat;

GET /testgzip.shtml HTTP/1.0
HOST: <yoursite>
USER-AGENT: Mozilla/5.0

...and got the reply...

HTTP/1.1 200 OK
Date: Wed, 06 Aug 2003 07:57:21 GMT
Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.2
6 FrontPage/5.0.2.2623 AuthMySQL/2.20
X-Powered-By: PHP/4.0.6
Connection: close
Content-Type: text/html

I thought it might be a HTTP/1.1 vs. HTTP/1.0 issue but it's not - it actually all depends on what encoding the client will accept - ie none of my requests included any accept-encoding headers so I recieved no encoding.

Instead if I try;

GET /testgzip.shtml HTTP/1.1
HOST: <yoursite>
USER-AGENT: Mozilla/5.0
CONNECTION: close
ACCEPT-ENCODING: gzip

...I get the reply...

HTTP/1.1 200 OK
Date: Wed, 06 Aug 2003 08:05:04 GMT
Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6a PHP/4.0.6 mod_perl/1.2
6 FrontPage/5.0.2.2623 AuthMySQL/2.20
X-Powered-By: PHP/4.0.6
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 90
X-Content-Encoded-By: class.gzip_encode 0.67
Connection: close
Content-Type: text/html

So the answer to your question is that the two systems you have tried work in different ways, hence produce different results.

- Tony

[wkitty42]

yes, the key being that the gzip encoding has to be listed in the accept encoding field that the "browser" sends to the server...

FWIW: there's a mod_gzip available for apache, too...

[ianevans]

Hmm..it's interesting that the PHP function I'm using is not sending the content-length header at all times though, since that's an aid to persistent connections whether the file is compressed or not. There's another php compression/cacheability function I can try...lemme give that a whirl and I'll see how that goes.