[ILUG] mod_gzip tutorial/introduction

[Padraig Brady]

They could be going through a proxy that wants to
do content filtering/indexing/someat and it sets
the "NO_ACCEPT_ENCODING" header entry?

Padraig.

> -----Original Message-----
> From: Donncha O Caoimh [mailto:donncha.ocaoimh at tradesignals.com]
> Sent: 19 February 2001 13:19
> To: Padraig Brady
> Cc: ilug at linux.ie
> 
> I meant that some versions of MSIE don't accept compressed 
> data for some
> reason. I watched the log files for a while and I can't explain the
> relationship between MSIE versions that accepted 
> gzip-encoding and those
> that don't, as the exact same versions of the browser acts 
> differently!
> 
> I grabbed a partial log this morning, filtered out images, image
> generating scripts, anything without "Mozilla", and a few 
> other requests so that only php3 page requests were left.
> Of 4059 requests, 2519 requests weren't compressed for some reason.
> Of those 2519 requests, 2385 requests returned "NO_ACCEPT_ENCODING",
> those browsers didn't support gzip-encoding.
> The rest were either Java jar files, or else too small to 
> compress well, and were sent "as-is".
> 
> The high figure for ""NO_ACCEPT_ENCODING" is rather strange since
> 99.9999% of our audience use version 4+ MSIE..
> 
> Donncha.
> 
> Padraig Brady wrote:
> > 
> > While working on content filtering code for squid I
> > came across this little beauty (i.e. gzipped compressed
> > HTTP streams). Example sites that use it are www.oracle.com
> > and search results from google (not the main page).
> > All major browsers support this of course, but as you
> > can imagine it complicates content filtering a little :-)
> > In mozilla if you go to: Edit->Preferences->Debug->Networking
> > you can see the "Accept-Encoding" field which
> > by default is set to: gzip,deflate,compress,identity
> > 
> > It's interesting what you say about some servers not
> > sending the content-encoding header entry. Are you sure
> > about this? If so I'll probably have to have some heuristic
> > for determining the stream contents when the encoding field
> > is not present :-( I can rip it from file easy enough, but
> > it'll slow things down a bit.