Forum Moderators: coopster
They both create a compressed string according to the manual.
I see examples of how to enable gzip with php with mention of "\x1f\x8b\x08\x00\x00\x00\x00\x00" along with crc and content size(uncompressed?), are these parts included automatically when using ob_gzhandler (or gzencode or gzcompress)?
I'm currently using ob_gzhandler and gzip testing pages say my site is gzipped.. but I'm not sure how technically accurate it is with regards to http header and file header(that x1f line) and where exactly they fit in.. wouldn't want it to break with a browser update if they all of a sudden decide to follow specs closely.
I suppose the http header expects a content length of the binary it's downloading.. BUT then the browser or application decoding the page expects the crc and content length of the page as well once it gets past the http header part and goes on to uncompressing? Which leads back to the above question of whether or not ob_gzhandler sends(or includes) the gzip file header, crc, content size?
gzhandler just works so I assume it's also sending the right stuff otherwise the pages would look garbled in the browser.
I was curious because I was thinking of how a caching system might work where the gzipped files were stored on the filesystem so php wouldn't have to do on the fly compression for each request.
I haven't started this though because I really need to get the basics memorized, I'm always referring to the manual and then searching the web for posts or examples to see how it may have been implemented previously.
Then I get overwhelmed by the things needed like http 1.0 and 1.1 protocols for expiration and cache control, when pages should expire, how to determine the last modified of a dynamic page, should I just use etag.. then http 1.0 caches might not work.. maybe just make it a server side cache for php and forget the browser/proxy caches. I lose focus quick hehe.. the original thought was how to store the gzip files to disk.. gzencode or gzcompress.. probably gzencode :P
