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.
Regards,
Arabinda
-----Original Message-----
From: André Warnier [mailto:aw@xxxxxxxxxx]
Sent: Wednesday, May 06, 2009 2:46 PM
To: users@xxxxxxxxxxxxxxxx
Subject: Re: Apache/2.0.47 - AIX - DEFLATE enabled - Content-Encoding for a page - shows blank - although it's gzip encoded
Nick Kew wrote:
> On 6 May 2009, at 08:41, Arabinda Sahoo wrote:
>
>> Actually I have a compelling reason to set - Content-Encoding to gzip
>> - for performance improvement.
>
> For ****s sake, take a step back!
>
> There's no way Apache makes such a meal of this. You have either a very
> broken
> application or a very confused configuration. Maybe both.
>
>> Although Compression is set for Apache - DEFLATE module, a few Pages
>> which are rendered by Actuate 8 report server - don't honour them.
>
> That just doesn't make sense (maybe English isn't your first language?).
> What are you expecting of mod_deflate, and how is it not performing?
>
>> As per you - I tried - mod_headers - but unsuccessfully
>> (Although Apache doc for mod_headers say that - these settings take
>> effect just before it is sent over the network!!!!)
>
> mod_headers should not be necessary for this. It adds to your complexity.
>
> Bottom line: for contents that are stored compressed on the server, use
> AddEncoding. For contents compressed on the fly, use mod_deflate.
> For anything else, RTFM and tell us why you're not using standard
> solutions.
>
Hi Nick.
No need to get upset.
As I understand the issue now (and as stated above by the OP),
mod_deflate seems to be doing fine in most cases.
However, it also seems that /some/ pages which are rendered by something
("Actuate 8 report server", which I have no idea what it is) are
actually compressed (?), but do /not/ come out with the correct
content-encoding.
From all that, I gather (now) that these specific pages are not static,
but generated on-the-fly (Arabinda, is that right ?).
So the question now would be : is there something (in the URI used to
request such a page for example) that allows to distinguish it from
other pages that do work ?
And does the problem concern /all/ the pages produced by that "Actuate 8
report server", or just some of them ?
Also (for Nick), while we are at it, /why/ would it be that a
content-encoding response header set unconditionally by mod_headers
would not come out ?
(the OP earlier posted the "Header" line used.)
---------------------------------------------------------------------
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: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
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: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|