Antwort: RE: [Mod_gzip] Request Handling
mod_gzip@lists.over.net
mod_gzip@lists.over.net
Fri, 10 Oct 2003 20:42:20 EDT
--part1_6c.32a99e28.2cb8abec_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hi Etienne...
This is Kevin again...
> You wrote...
>
> Wow. Very good explanation.
>
> The application server is WebSphere 5.0
Ah... okay. Now we are getting somewhere.
This all-at-once both clears up some mysteries and
creates new ones.
This is an IBM specific product.
Caveat: You really should be working with your IBM representative
on this one. WebSphere is THEIR product and it is NOT open-source.
In case you were not aware... IBM's HTTPD Server is NOT
'standard Apache' as downloaded from the official Apache site.
It DOES start out that way... but IBM re-writes it and
re-packages it... and indeed... they do have Apache's
permission to do so.
IBM's HTTPD Server says it is 'Powered by Apache X.X' but it
really is nothing more than 'regular' Apache downloaded from
the public domain and then IBM adds a whole bunch of
proprietary stuff to it and releases it under another name.
IBM has never released the full source code and/or patches for HTTPD
back to the Apache organization so no one really knows for sure what
they actually do to open-source Apache before they re-package it.
It's obvious that they add SSL ( open source mod_ssl ? ) and
some LDAP stuff of theirs and wrap it all up in an InstallShield
package but none of that is a miltary secret. It says so right
in their own documentation.
What is also 'documented' is the fact that they RENAME the
low-level Apache BUFF I/O file/stream handle names so that
any module code that was referring to these names as they
are in the open-source version of Apache won't work anymore.
This was not actually intentional. It just worked out that way.
mod_gzip happens to fall into that category for the IBM HTTPD
re-package of Apache 1.3.x
Apache 2.0 did away with the BUFF I/O interface itself so this
'name game' is no longer an issue for mod_gzip and IBM HTTPD
but for all 1.3.x 're-packaged' versions of Apache from IBM
you had to have a special version of mod_gzip for IBM HTTPD
that knew what those IBM specific 'names' were.
It's really kind of a laugh the way this all happened. What really
went down is that IBM needed to tweak the BUFF I/O structures
a little bit to accomodate some of the proprietary code they
were 'adding' to Apache but they never really intended to cause
incompatibilities.... but
in order to find all the occurrences of the low-level handle names
in the Apache code they just did what any programmer faced with
this enormous task would probably do and they 'renamed' the structure
members themselves and then just let the compiler find all the
references to it. Once they had all been 'traced' this way they just
left the 'renamed' structure members as they were... hence the
'name game' for other modules that were referencing the original
Apache open-source name(s).
IBM itself has the 'right' version of mod_gzip for their own
IBM HTTPD re-write of Apache. They contacted me directly
when it became a real problem and I helped them 'get it right'.
If you need that IBM HTTPD specific version of mod_gzip
for Apache 1.3.x based versions of HTTPD then either ask
your IBM rep for it or search the Web. It's also out there on
a few IBM websites somewhere.
You could also just ask for it here on the forum. I know for
a fact that some people on this forum are using mod_gzip
successfully with their IBM HTTPD Server(s).
> and it does have a module that gets loaded in the configuration file.
Of course. Since you say it's WebSphere 5.0 then let me
take a guess at the module NAME. Is it something like...
mod_was_ap20_http.so
This would mean that you are using IBM's altered version
of the new Apache 2.0 Server as the actual HTTP Server
for WebSphere... and NOT the older (stable) Apache 1.3 Server.
AFAIK Websphere 5.x series ( latest release is now 5.2 )
defaults to using IBM's own 'altered' version of Apache 2.0
unless you install it manually for some 'other' supported
HTTP Server.
Webshphere is advertised to work with all of the following
HTTP Servers...
- Apache HTTP Server V1.3.x ( Actual Apache... not IBM altered version )
- Domino Web server V6
- Domino Web server V5
- IBM HTTP Server powered by Apache 2.0 ( Their 'altered' version. AKA:
IBMHTTPD)
- IBM HTTP Server powered by Apache 1.3 ( Their 'altered' version. AKA:
IBMHTTPD)
- Internet Service Manager Web Server ( AKA: Microsoft IIS Server )
- Sun One ( IPlanet ) Web Server
Exactly which one are you really using and on what
PLATFORM? Windows, Standard UNIX, Linux, other?
It makes a big difference.
I am going to 'assume' that you just installed WebSphere 5.x
using the defaults and that IBM's altered version of Apache 2.0
is the actual HTTP 'Server' we are talking about here.
This assumption fits in nicely with some of the 'mysteries'
and automatically answers some of your new questions... but
it also brings up a few 'new' mysteries.
> When I specify a log file for mod_gzip I can see that the
> application server requests are being compressed (if chunks
> are enabled), does this mean that it is actually working?
I assume you meant to say 'the application server responses
are being compressed' since nothing is actually compressing
any 'requests' at all. I'm sure that was just a typo.
It would 'appear' that the 'responses' are being compressed, yes.
The logs don't lie. If if says that a 'response' was compressed
60 or 70 percent or whatever than that is, in fact, what happened...
...but there are some ambiguities in your statement that need
to be cleared up.
What do you mean by 'if chunks are enabled' ?
Are you talking about the mod_gzip configuration switch
that allows mod_gzip to compress 'chunked' data coming
out of the back-end... or are you talking about Apache's own
'chunking' switches?
Here is the deal with that...
You have to specifically TELL mod_gzip that it's OK to
'dechunk' responses that are coming back from a CGI
script or back-end server with "Transfer-Encoding: chunked",
or mod_gzip WILL NOT COMPRESS these responses.
Maybe that's all you are seeing at this time.
It's not a bug... it's a 'feature'.
If ALL of the responses coming from the back-end are using
"Transfer-Encoding: chunked" then you MUST allow mod_gzip
to 'dechunk' or it is unable to compress the response.
Okay... I can hear you asking the million dollar question...
WHY?
Simple... it's because of a huge flaw in the way HTTP was
designed and implemented.
'Transfer-Encoding: chunked' was just a hack laid into the
HTTP protocol to handle the cases when it's impossible
to know what the actual length of the response content
is before you have to send the response header(s).
It looked good on paper and it works in most cases but
they didn't quite realize what was going to happen to
other parts of the HTTP specification and how hard it
would be to maintain RFC compliance.
The real screw-up was that this 'chunked' encoding scheme
is actually a 'Transport' layer mechanism to help the other
side know where the end of the data is... but the actual
'chunking' bytes get mixed right in with the presentation
layer content. Therein lies the problem. It's a bad mix
of 'transport' and 'presentation' layer as far as the OSI
communications models go and there's a big penalty
to be paid for doing it this way.
'Transfer-encoding: chunked' is a whacky little scheme
whereby the data is being sent out in 'chunks' that can
be of variable length at any moment ( you never know what
size the next chunk is until it starts arriving ). The actual
'chunking' information is always just this weird insertion
of ASCII hex characters followed by Carriage-Return and/or
Line-Feed characters regardless of whether the data itself is
binary or text.
So the only way to know that you have received ALL of the
response is to watch for 'chunk length' of ZERO and then
clear through some more Carriage-Returns / Line-Feeds.
That's the EOD ( End of data ) signal.
Ok... Ok... I know... MORE than you ever wanted to know,
I'm sure... but my point is this...
If anything is going to have a chance at COMPRESSING this
mess then it CANNOT be COMPRESSED with all these
stupid ASCII chunking characters sitting in the middle of
the presentation content or the client that's receiving the
response won't have the faintest freakin' idea where the
end of the data is and it will never be able to DECOMPRESS
the presentation content correctly.
So... if mod_gzip is seeing "chunked" response data... the
only chance it has of doing a proper compression is to
REMOVE the 'chunking' information from the middle of the
body data where the back-end server is writing this nonsense
and THEN compress the 'pure' response data... minus the
'chunking' crap.
The only reason you really should ever be using
"Transfer-encoding: chunked" is when it is IMPOSSIBLE
to supply the standard HTTP "Content-Length:" response
header.
Once mod_gzip has 'dechunked' the response and compressed
the data it REMOVES the "Transfer-encoding: chunked" response
header because ( guess why! ) it's no longer needed! Once mod_gzip
has compressed the response it knows EXACTLY how long
the 'response' data is and it now inserts the 'correct' "Content-length:"
header ( which is really what the back-end should have done in
the first place ).
None of this applies to actual 'streaming' data responses, of course,
which very often have the "Transfer-encoding: chunked" header...
but this is as it should be since you shouldn't be compressing
those kinds of never-ending responses, anyway. Most actual
streaming data ( video, audio ) is already well-compressed and
running it through some text-oriented compression algorithm
like GZIP is just a waste of time.
As if this all wasn't complicated enough... it's actually SUPPOSED
to be legal to do something like this...
Transfer-encoding: chunked, gzip
...but there is no browser in the world that is coded to handle this
so you just can't 'go there'.
Besides... you still run into a 'can of worms' when it comes to
the 'chunking' bytes for reasons already stated. The transport
layer 'chunking' bytes are mixed right in with the presentation
layer body data so if you just apply GZIP to the 'chunked'
data then the other side totally loses the ability to do the
'chunking' scheme and it will just 'hang'.
Conversely... if you remove the chunking bytes first and then
gzip things and then turn around and SEND it by inserting
NEW 'chunking' bytes right into the middle of the compressed
data then the header no longer matches reality.
Since browsers are supposed to read these kind of multiple
value headers BACKWARDS when the data arrives then
what you just done then is changed...
Transfer-Encoding: chunked, gzip
to
Transfer-Encoding: gzip, chunked
and just like the other scenario... you are in for a world of
hurt if the client doesn't interpret this exactly right and it
tries to DECOMPRESS something that has these funny
ASCII chunking bytes embedded in it. The ZLIB or GZIP
decompressor will blow sky high.
Does this all sound like a mess and a bad mixture
of transport and presentation layer concepts?
Well it should... because that's exactly what it is.
> I have not specified "mod_gzip_item_include handler xxxxx" but
> it seems to be working, how can this be?
Because it appears that you are using IBM's altered version
of Apache 2.0 and NOT Apache 1.3... so the whole discussion
about specifiying a 'handler' name does NOT APPLY.
The whole 'handler' scheme was actually done away with
in Apache 2.0 and now everything is supposed to just be
using the 'filter' chain and the 'Bucket Brigade' thing they
have come with.
It probably IS WORKING.
If you are NOT using IBM's hacked up version of Apache 2.0
then it should NOT work unless you have that 'handler' statement.
> (From your response it seemed like the handler directive would be
> required for it to work)
See above. It was my fault in previous message to not make it
clear that this whole 'handler' thing really only applies to
Apache 1.3.x ( and rewrites of it such as IBM's HTTPD Server ).
> Why does it only work when chunks are enabled?
> Etienne
I don't really know. See above. It really all depends on
what you mean by 'when chunks are enabled?'
Enabled where? IBM HTTPD, Webshpere back-end, or mod_gzip?
If you really are using any flavor of Apache 2.0 AND you have the
right mod_gzip for Apache 2.0 then the 'chunking' should not
have much to do with it. It should work either way as long as
you have given mod_gzip permission to 'dechunk'.
You may simply have just found YABIA2 ( Yet Another Bug In Apache 2.x ).
More info will be needed to nail it down and you might have to
use the DEBUG version of mod_gzip itself to find out what
is going on.
My only guess would be that if you are talking about turning
'chunking' on/off at the back-end server then MAYBE the
responses are (then) showing up without EITHER...
"Transfer-encoding: chunked"
OR
"Content-length: xxxx'.
If that's the case... then mod_gzip can't compress the responses
because the response violates RFC's and there's no way to know
where the end of the data is unless the back-end Server just
closes the connection ( which I doubt it is doing if Keep-Alive
is also in effect ).
Later...
Kevin
PS: Here is that 'other' message where the 'handler' thing was
explained and, as you can see, it works just fine when you
have the NAME right... but this ONLY applies to Apache 1.3.x...
> Jin wrote...
>
> I guess that depends on what application server are you using. I use
> mod_zip to compress responses from Apple's WebObjects which is a java
> application server and uses a apache module mod_WebObjects to handle
> request/response between apache and WebObjects, and it works fine. I
> just need to add handler "WebObjects" in the mod_gzip configuration.
> Hopefully this information might be useful to you.
> Jin
--part1_6c.32a99e28.2cb8abec_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><FONT COLOR=3D"#0000ff" SIZE=3D2><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">Hi Etienne...<BR>
This is Kevin again...<BR>
<BR>
> You wrote...<BR>
><BR>
> Wow. Very good explanation.<BR>
><BR>
> The application server is WebSphere 5.0 <BR>
<BR>
Ah... okay. Now we are getting somewhere.<BR>
<BR>
This all-at-once both clears up some mysteries and<BR>
creates new ones.<BR>
<BR>
This is an IBM specific product.<BR>
<BR>
Caveat: You really should be working with your IBM representative<BR>
on this one. WebSphere is THEIR product and it is NOT open-source.<BR>
<BR>
In case you were not aware... IBM's HTTPD Server is NOT<BR>
'standard Apache' as downloaded from the official Apache site.<BR>
<BR>
It DOES start out that way... but IBM re-writes it and<BR>
re-packages it... and indeed... they do have Apache's<BR>
permission to do so.<BR>
<BR>
IBM's HTTPD Server says it is 'Powered by Apache X.X' but it<BR>
really is nothing more than 'regular' Apache downloaded from<BR>
the public domain and then IBM adds a whole bunch of<BR>
proprietary stuff to it and releases it under another name.<BR>
<BR>
IBM has never released the full source code and/or patches for HTTPD <BR>
back to the Apache organization so no one really knows for sure what<BR>
they actually do to open-source Apache before they re-package it.<BR>
<BR>
It's obvious that they add SSL ( open source mod_ssl ? ) and<BR>
some LDAP stuff of theirs and wrap it all up in an InstallShield<BR>
package but none of that is a miltary secret. It says so right<BR>
in their own documentation.<BR>
<BR>
What is also 'documented' is the fact that they RENAME the<BR>
low-level Apache BUFF I/O file/stream handle names so that<BR>
any module code that was referring to these names as they<BR>
are in the open-source version of Apache won't work anymore.<BR>
<BR>
This was not actually intentional. It just worked out that way.<BR>
<BR>
mod_gzip happens to fall into that category for the IBM HTTPD<BR>
re-package of Apache 1.3.x<BR>
<BR>
Apache 2.0 did away with the BUFF I/O interface itself so this<BR>
'name game' is no longer an issue for mod_gzip and IBM HTTPD<BR>
but for all 1.3.x 're-packaged' versions of Apache from IBM <BR>
you had to have a special version of mod_gzip for IBM HTTPD<BR>
that knew what those IBM specific 'names' were.<BR>
<BR>
It's really kind of a laugh the way this all happened. What really<BR>
went down is that IBM needed to tweak the BUFF I/O structures<BR>
a little bit to accomodate some of the proprietary code they<BR>
were 'adding' to Apache but they never really intended to cause <BR>
incompatibilities.... but<BR>
in order to find all the occurrences of the low-level handle names<BR>
in the Apache code they just did what any programmer faced with<BR>
this enormous task would probably do and they 'renamed' the structure<BR>
members themselves and then just let the compiler find all the<BR>
references to it. Once they had all been 'traced' this way they just<BR>
left the 'renamed' structure members as they were... hence the<BR>
'name game' for other modules that were referencing the original<BR>
Apache open-source name(s).<BR>
<BR>
IBM itself has the 'right' version of mod_gzip for their own<BR>
IBM HTTPD re-write of Apache. They contacted me directly<BR>
when it became a real problem and I helped them 'get it right'.<BR>
<BR>
If you need that IBM HTTPD specific version of mod_gzip<BR>
for Apache 1.3.x based versions of HTTPD then either ask<BR>
your IBM rep for it or search the Web. It's also out there on<BR>
a few IBM websites somewhere.<BR>
<BR>
You could also just ask for it here on the forum. I know for<BR>
a fact that some people on this forum are using mod_gzip<BR>
successfully with their IBM HTTPD Server(s).<BR>
<BR>
> and it does have a module that gets loaded in the configuration file.<B=
R>
<BR>
Of course. Since you say it's WebSphere 5.0 then let me<BR>
take a guess at the module NAME. Is it something like...<BR>
<BR>
mod_was_ap20_http.so<BR>
<BR>
This would mean that you are using IBM's altered version<BR>
of the new Apache 2.0 Server as the actual HTTP Server<BR>
for WebSphere... and NOT the older (stable) Apache 1.3 Server.<BR>
<BR>
AFAIK Websphere 5.x series ( latest release is now 5.2 )<BR>
defaults to using IBM's own 'altered' version of Apache 2.0<BR>
unless you install it manually for some 'other' supported<BR>
HTTP Server.<BR>
<BR>
Webshphere is advertised to work with all of the following<BR>
HTTP Servers...<BR>
<BR>
- Apache HTTP Server V1.3.x ( Actual Apache... not IBM altered version )<BR>
- Domino Web server V6<BR>
- Domino Web server V5<BR>
- IBM HTTP Server powered by Apache 2.0 ( Their 'altered' version. AKA: IBMH=
TTPD)<BR>
- IBM HTTP Server powered by Apache 1.3 ( Their 'altered' version. AKA: IBMH=
TTPD)<BR>
- Internet Service Manager Web Server ( AKA: Microsoft IIS Server )<BR>
- Sun One ( IPlanet ) Web Server<BR>
<BR>
Exactly which one are you really using and on what<BR>
PLATFORM? Windows, Standard UNIX, Linux, other? <BR>
<BR>
It makes a big difference.<BR>
<BR>
I am going to 'assume' that you just installed WebSphere 5.x<BR>
using the defaults and that IBM's altered version of Apache 2.0<BR>
is the actual HTTP 'Server' we are talking about here.<BR>
<BR>
This assumption fits in nicely with some of the 'mysteries'<BR>
and automatically answers some of your new questions... but<BR>
it also brings up a few 'new' mysteries.<BR>
<BR>
> When I specify a log file for mod_gzip I can see that the <BR>
> application server requests are being compressed (if chunks <BR>
> are enabled), does this mean that it is actually working? <BR>
<BR>
I assume you meant to say 'the application server responses<BR>
are being compressed' since nothing is actually compressing<BR>
any 'requests' at all. I'm sure that was just a typo.<BR>
<BR>
It would 'appear' that the 'responses' are being compressed, yes.<BR>
The logs don't lie. If if says that a 'response' was compressed<BR>
60 or 70 percent or whatever than that is, in fact, what happened...<BR>
<BR>
...but there are some ambiguities in your statement that need<BR>
to be cleared up.<BR>
<BR>
What do you mean by 'if chunks are enabled' ?<BR>
<BR>
Are you talking about the mod_gzip configuration switch<BR>
that allows mod_gzip to compress 'chunked' data coming<BR>
out of the back-end... or are you talking about Apache's own<BR>
'chunking' switches?<BR>
<BR>
Here is the deal with that...<BR>
<BR>
You have to specifically TELL mod_gzip that it's OK to<BR>
'dechunk' responses that are coming back from a CGI<BR>
script or back-end server with "Transfer-Encoding: chunked",<BR>
or mod_gzip WILL NOT COMPRESS these responses.<BR>
<BR>
Maybe that's all you are seeing at this time.<BR>
<BR>
It's not a bug... it's a 'feature'.<BR>
<BR>
If ALL of the responses coming from the back-end are using<BR>
"Transfer-Encoding: chunked" then you MUST allow mod_gzip<BR>
to 'dechunk' or it is unable to compress the response.<BR>
<BR>
Okay... I can hear you asking the million dollar question...<BR>
<BR>
WHY?<BR>
<BR>
Simple... it's because of a huge flaw in the way HTTP was<BR>
designed and implemented.<BR>
<BR>
'Transfer-Encoding: chunked' was just a hack laid into the<BR>
HTTP protocol to handle the cases when it's impossible<BR>
to know what the actual length of the response content<BR>
is before you have to send the response header(s).<BR>
<BR>
It looked good on paper and it works in most cases but<BR>
they didn't quite realize what was going to happen to<BR>
other parts of the HTTP specification and how hard it<BR>
would be to maintain RFC compliance.<BR>
<BR>
The real screw-up was that this 'chunked' encoding scheme<BR>
is actually a 'Transport' layer mechanism to help the other<BR>
side know where the end of the data is... but the actual <BR>
'chunking' bytes get mixed right in with the presentation<BR>
layer content. Therein lies the problem. It's a bad mix<BR>
of 'transport' and 'presentation' layer as far as the OSI<BR>
communications models go and there's a big penalty<BR>
to be paid for doing it this way. <BR>
<BR>
'Transfer-encoding: chunked' is a whacky little scheme <BR>
whereby the data is being sent out in 'chunks' that can<BR>
be of variable length at any moment ( you never know what<BR>
size the next chunk is until it starts arriving ). The actual<BR>
'chunking' information is always just this weird insertion <BR>
of ASCII hex characters followed by Carriage-Return and/or<BR>
Line-Feed characters regardless of whether the data itself is<BR>
binary or text.<BR>
<BR>
So the only way to know that you have received ALL of the<BR>
response is to watch for 'chunk length' of ZERO and then<BR>
clear through some more Carriage-Returns / Line-Feeds.<BR>
That's the EOD ( End of data ) signal.<BR>
<BR>
Ok... Ok... I know... MORE than you ever wanted to know,<BR>
I'm sure... but my point is this...<BR>
<BR>
If anything is going to have a chance at COMPRESSING this<BR>
mess then it CANNOT be COMPRESSED with all these <BR>
stupid ASCII chunking characters sitting in the middle of<BR>
the presentation content or the client that's receiving the<BR>
response won't have the faintest freakin' idea where the<BR>
end of the data is and it will never be able to DECOMPRESS<BR>
the presentation content correctly.<BR>
<BR>
So... if mod_gzip is seeing "chunked" response data... the<BR>
only chance it has of doing a proper compression is to<BR>
REMOVE the 'chunking' information from the middle of the<BR>
body data where the back-end server is writing this nonsense<BR>
and THEN compress the 'pure' response data... minus the<BR>
'chunking' crap.<BR>
<BR>
The only reason you really should ever be using<BR>
"Transfer-encoding: chunked" is when it is IMPOSSIBLE<BR>
to supply the standard HTTP "Content-Length:" response<BR>
header.<BR>
<BR>
Once mod_gzip has 'dechunked' the response and compressed<BR>
the data it REMOVES the "Transfer-encoding: chunked" response<BR>
header because ( guess why! ) it's no longer needed! Once mod_gzip<BR>
has compressed the response it knows EXACTLY how long <BR>
the 'response' data is and it now inserts the 'correct' "Content-length:"<BR=
>
header ( which is really what the back-end should have done in<BR>
the first place ).<BR>
<BR>
None of this applies to actual 'streaming' data responses, of course,<BR>
which very often have the "Transfer-encoding: chunked" header...<BR>
but this is as it should be since you shouldn't be compressing<BR>
those kinds of never-ending responses, anyway. Most actual<BR>
streaming data ( video, audio ) is already well-compressed and<BR>
running it through some text-oriented compression algorithm<BR>
like GZIP is just a waste of time.<BR>
<BR>
As if this all wasn't complicated enough... it's actually SUPPOSED<BR>
to be legal to do something like this...<BR>
<BR>
Transfer-encoding: chunked, gzip<BR>
<BR>
...but there is no browser in the world that is coded to handle this<BR>
so you just can't 'go there'.<BR>
<BR>
Besides... you still run into a 'can of worms' when it comes to<BR>
the 'chunking' bytes for reasons already stated. The transport<BR>
layer 'chunking' bytes are mixed right in with the presentation<BR>
layer body data so if you just apply GZIP to the 'chunked'<BR>
data then the other side totally loses the ability to do the<BR>
'chunking' scheme and it will just 'hang'.<BR>
<BR>
Conversely... if you remove the chunking bytes first and then<BR>
gzip things and then turn around and SEND it by inserting<BR>
NEW 'chunking' bytes right into the middle of the compressed<BR>
data then the header no longer matches reality.<BR>
<BR>
Since browsers are supposed to read these kind of multiple<BR>
value headers BACKWARDS when the data arrives then <BR>
what you just done then is changed...<BR>
<BR>
Transfer-Encoding: chunked, gzip<BR>
to <BR>
Transfer-Encoding: gzip, chunked<BR>
<BR>
and just like the other scenario... you are in for a world of<BR>
hurt if the client doesn't interpret this exactly right and it<BR>
tries to DECOMPRESS something that has these funny<BR>
ASCII chunking bytes embedded in it. The ZLIB or GZIP<BR>
decompressor will blow sky high.<BR>
<BR>
Does this all sound like a mess and a bad mixture <BR>
of transport and presentation layer concepts?<BR>
<BR>
Well it should... because that's exactly what it is.<BR>
<BR>
> I have not specified "mod_gzip_item_include handler xxxxx" but <BR>
> it seems to be working, how can this be? <BR>
<BR>
Because it appears that you are using IBM's altered version<BR>
of Apache 2.0 and NOT Apache 1.3... so the whole discussion<BR>
about specifiying a 'handler' name does NOT APPLY.<BR>
<BR>
The whole 'handler' scheme was actually done away with<BR>
in Apache 2.0 and now everything is supposed to just be<BR>
using the 'filter' chain and the 'Bucket Brigade' thing they<BR>
have come with.<BR>
<BR>
It probably IS WORKING. <BR>
<BR>
If you are NOT using IBM's hacked up version of Apache 2.0<BR>
then it should NOT work unless you have that 'handler' statement.<BR>
<BR>
> (From your response it seemed like the handler directive would be <BR>
> required for it to work)<BR>
<BR>
See above. It was my fault in previous message to not make it<BR>
clear that this whole 'handler' thing really only applies to <BR>
Apache 1.3.x ( and rewrites of it such as IBM's HTTPD Server ).<BR>
<BR>
> Why does it only work when chunks are enabled?<BR>
> Etienne<BR>
<BR>
I don't really know. See above. It really all depends on<BR>
what you mean by 'when chunks are enabled?'<BR>
<BR>
Enabled where? IBM HTTPD, Webshpere back-end, or mod_gzip?<BR>
<BR>
If you really are using any flavor of Apache 2.0 AND you have the<BR>
right mod_gzip for Apache 2.0 then the 'chunking' should not<BR>
have much to do with it. It should work either way as long as<BR>
you have given mod_gzip permission to 'dechunk'.<BR>
<BR>
You may simply have just found YABIA2 ( Yet Another Bug In Apache 2.x=20=
).<BR>
More info will be needed to nail it down and you might have to<BR>
use the DEBUG version of mod_gzip itself to find out what <BR>
is going on.<BR>
<BR>
My only guess would be that if you are talking about turning<BR>
'chunking' on/off at the back-end server then MAYBE the<BR>
responses are (then) showing up without EITHER...<BR>
"Transfer-encoding: chunked"<BR>
OR <BR>
"Content-length: xxxx'.<BR>
<BR>
If that's the case... then mod_gzip can't compress the responses <BR>
because the response violates RFC's and there's no way to know<BR>
where the end of the data is unless the back-end Server just<BR>
closes the connection ( which I doubt it is doing if Keep-Alive<BR>
is also in effect ).<BR>
<BR>
Later...<BR>
Kevin<BR>
<BR>
PS: Here is that 'other' message where the 'handler' thing was<BR>
explained and, as you can see, it works just fine when you<BR>
have the NAME right... but this ONLY applies to Apache 1.3.x...<BR>
<BR>
> Jin wrote...<BR>
><BR>
> I guess that depends on what application server are you using. I use </=
FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 F=
AMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> mod_zip to compress res=
ponses from Apple's WebObjects which is a java </FONT><FONT COLOR=3D"#00000=
0" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=
=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> application server and=20=
uses a apache module mod_WebObjects to handle </FONT><FONT COLOR=3D"#000000=
" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"=
Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> request/response betwee=
n apache and WebObjects, and it works fine. I </FONT><FONT COLOR=3D"#=
000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FA=
CE=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> just need to add handle=
r "WebObjects" in the mod_gzip configuration.</FONT><FONT COLOR=3D"#000000"=
style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"A=
rial" LANG=3D"0"> <BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> Hopefully this informat=
ion might be useful to you.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROU=
ND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">=20=
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">> Jin</FONT><FONT COLOR=
=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERI=
F" FACE=3D"Arial" LANG=3D"0"> <BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"><BR>
</FONT></HTML>
--part1_6c.32a99e28.2cb8abec_boundary--