Arabinda Sahoo wrote:
Yes, Andre.
MOD_DEFLATE setting as done in my httpd.conf as follows - perfectly does - one
part of work - which is - Compression - for all Pages.
<Location />
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|tar)$ no-gzip dont-vary
</Location>
And also it does set "Content-Encoding=gzip" (Which I can see using "Fiddler"
tool) - 90% of the time.
But for 10% of my pages - the Compression happens, but Content-Encoding="" is
set. I can check this using Fiddler again.
I will tend to think that it is an Apache issue.
Because, my application is not aware that - Apache compression has been enabled.
And if Apache is indeed compressing a page, now whose responsibility it becomes
- to set the Content-Encoding=gzip???
Apache is not behaving as expected.
So, IE7 explorer cannot recognize this as a compressed page and fails.
I am happy to send you and Nick the entire httpd.conf file - if attachments are
allowed in this forum.
Ok, taking all that you write above at face value,
is there /something/ (URL, size, type, whatever) that distinguishes the
10% of pages that result in a 'Content-encoding: "" ' header, from the
others ?
Also, can you give us a short explanation of how these pages are being
generated ? I mean what is the application that generates them, where
does it live, how does Apache get that content, etc..
And does that application /ever/ by itself generate compressed content ?
Can you give us an example of the response headers in both cases (copy
and paste from Fiddler) ?
I'm just plucking at straws here, trying to figure out the reason for
the 10%..
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
