Thanks for the response, I'm looking into the bug report right now, but
I'm using Firefox for my testing though, the issue is if I was
getting"Content-Encoding: gzip" in the return header I would start
looking at different solutions, but my problem doesn't leave the
server, are you using the standard ADP parser or the fancy parser? Did
you do any more changes to your setting for this to take hold?
As for the difference between "true" and "yes" in the config file, it
works both ways, there is a map in the C file that parses the startup
file, that equates "1" , "true" , "yes" and "on" to the same thing, I
may have gone too far debugging this, as I am convinced that this works
otherwise there would have been more complaining, but what am I missing
in the config!
Nader Henein
Mark Mcgaha wrote:
I have been playing with gziped pages for a while. My config is:
ns_section "ns/server/${servername}/adp/compress"
ns_param enable yes
ns_param level 1
ns_param minsize 4096
I assume that enable yes is different than enable true. I was also
having a problem where compressed pages only showed a white screen in
ie. Here is the bug report and fix that I posted.
http://sourceforge.net/tracker/index.php?func=detail&aid=1158047&group_id=3152&atid=103152
Good luck.
On 7/20/05, Nader Henein <[EMAIL PROTECTED]> wrote:
Ok guys,
I may be missing something, so I'm going to detail what I've done and you
can tell me what I've missed while setting up ns_ad_compress on my server,
for reference, we use AOL Server 4.0.10 and our flavor of ACS (scalled down
to trim the fat)
What I did:
- Compiled the AOL Server with zlib enabled and got positive confirmation on
all compression relevant messages
checking whether to include zlib compression support... yes
checking for zlib.h... yes
checking for compress2 in -lz... yes
- Added the following lines in my .tcl config file
ns_section ns/server/bayt/adp/compress
ns_param enable true
ns_param level 4
ns_param minsize 0
- placed <% ns_adp_compress %> at the end of every ADP file, we generate ADP
files from multiple module files, so this was a 2 second job.
As you may have imagined, this did nothing, I know this because when I
restarted the server and went to view the response headers on Firefox, they
didn't have the "Content-Encoding: gzip" entry.
So I embarked on a crusade to debug and figure out what I missed, initially
I stayed on the TCL code and when I exhausted that, I turned to the AOL
Server C code (very clean by the way) I started looking at adprequest.c,
specifically the AdpFlush function, it detailed a set of checks to initiate
compression as follows,
/*
* Should we compress the response? If the ADP requested it with
* ns_adp_compress,
* IF
* enabled in the server config
* headers haven't been sent yet
* not a HEAD request
* streaming isn't turned on
* the response meets the minimum size per the config
* the browser indicates it can accept it
* THEN do
* we compress the response.
*/
if ( itPtr->adp.compress
&& itPtr->servPtr->adp.compress.enable
&& !(conn->flags & NS_CONN_SENTHDRS)
&& !(conn->flags & NS_CONN_SKIPBODY)
&& !stream
&& len >= itPtr->servPtr->adp.compress.minsize
&& (ahdr =
Ns_SetIGet(Ns_ConnHeaders(conn),"Accept-Encoding")) != NULL
&& strstr(ahdr, "gzip") != NULL
&& Ns_CompressGzip(buf, len,
&cds,itPtr->servPtr->adp.compress.level) == NS_OK) {
I went through these checks and everything was in order, then I started
sticking comments like these in the C code and re-compiling the server,
Ns_LogSeverity severity;
severity = Notice;
Ns_Log(severity, "%s", "fooo" );
To my surprise no request was going into AdpFlush all the request where
going through NsAdpFlush and I can't find any documentation on what would
cause this, at some point I thought it may be an interpreter issue, so I
switched to fancy and back again and that still made no difference.
This is probably some one liner in the config that I missed somehow, a
little help would be nice.
--
Nader S. Henein
Senior Applications Architect
Bayt.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the
email message. You can leave the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
--
Nader S. Henein
Senior Applications Developer
Bayt.com
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
|
