Antwort: RE: [Mod_gzip] Request Handling
Richards, Etienne (EM, PTL)
mod_gzip@lists.over.net
Fri, 10 Oct 2003 08:20:23 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------=_NextPartTM-000-01e00589-a55b-4525-a8cf-3d96c7c07027
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C38F28.E15E3FE0"
------_=_NextPart_001_01C38F28.E15E3FE0
Content-Type: text/plain
Wow. Very good explanation.
The application server is WebSphere 5.0 and it does have a module that gets
loaded in the configuration file.
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 have not specified "mod_gzip_item_include handler xxxxx" but it seems to
be working, how can this be? (From your response it seemed like the handler
directive would be required fro it to work)
Why does it only work when chunks are enabled?
Etienne
-----Original Message-----
From: TOKILEY@aol.com [mailto:TOKILEY@aol.com]
Sent: Thursday, October 09, 2003 10:43 PM
To: mod_gzip@lists.over.net
Cc: TOKILEY@aol.com
Subject: Re: Antwort: RE: [Mod_gzip] Request Handling
Hi Etienne...
This is Kevin Kiley...
Someone mentioned this a few messages back but since
you still haven't said which 'Application Server' you are
using I thought I would also mention this...
...sometimes the only way to get the output of an 'Application
Server' compressed ( versus simple CGI backend ) is to make
sure you have an 'include handler' statement for this particular
back-end Server in your mod_gzip config file.
The way most 'Application Servers' work with Apache follows
the original 'Coldfusion' model.
The authors of the Application Server usually write a small
'mod_xxxxx' module of their own for Apache and you usually
have to install that into your Apache Server.
What this module usually does is 'intercept' requests that
the Application Server is supposed to handle.
Almost all of these "Application Server" modules do this in
the same way the original 'ColdFusion' Apache module
did it. They register a 'handler' name into the request
structure at one of the low-level Apache 'hooks' and then
some 'higher-up' hook sees the 'handler' name and
knows that this request is meant for that particular
Application Server.
Example: At the lowest level hook possible... the
mod_coldfusion module registers a 'handler' name
of 'coldfusion' on any request that Coldfusion is
supposed to handle.
The problem here is that once a higher level hook
has 'seen' this handler name and sent the transaction
to the application server... it usually does a 'Return ZERO'
from the hook and in Apache code this means that no
other handlers get called for that transaction.
So... to make a long, boring story short... it usually isn't
enough to just enter some URI inclusion 'rules' in
the mod_gzip config and expect them to get compressed
if the request gets passed off to a 'back end' Application
Server.
You must ALSO have something like this ( which is what
works for ColdFusion... )
mod_gzip_item_include handler coldfusion
Now what happens is that mod_gzip has a chance to
intercept the transactions that are going to be given
a 'handler' name of 'coldfusion' but ONLY if the URI
matches some other 'regular' rule that you have
established for compressing output.
I know this all sounds a little complicated but many
people are not aware of this 'handler' scheme in Apache
unless they use something like ColdFusion.
It's a little obscure but it's the way Apache works.
Any module that wanted to intercept transactions for
back-end servers using this 'handler name' scheme would
have to have a similar parameter so the NAME of the
handler can be set at runtime.
If your 'Application Server' does NOT have it's own small
'mod_xxx' module that needs to be installed into Apache
and/or does not follow this standard 'ColdFusion' approach
I would be curious to know exactly how it DOES work?
Later...
Kevin
PS: The actual NAME of the handler that is going to be
registered inside Apache does NOT necessarily have
to match the name of the Application Server module that
gets installed into Apache.
In the case of ColdFusion... they just 'happen' to be the
same. The Application Server module you install is called
'mod_coldfusion' and the 'handler' name just happens to
be 'coldfusion' as well ( lowercase ).
In truth... the ONLY way to be SURE what the actual 'handler'
name might be is to look at the source code for the Application
Server module and see exactly what 'handler' name they are
registering at runtime.
The name of the module could be mod_super_back_end_server
but the 'handler' name being registered could be anything such
as 'super_back_end_server_whatchamacallit'.
It isn't a military secret so anyone familiar with the Application
Server should know what this 'handler' name is... but if things
don't seem to work then the first thing to verify is that you
have the right HANDLER NAME for this particular
Application Server. Don't make any 'assumptions' about it.
In a message dated 10/9/2003 5:20:29 AM Central Daylight Time,
Michael.Schroepl@telekurs.de writes:
Hi Etienne,
> Is this functionality currently in the mod_gzip module or
> is that something that we would have to request from you?
please tell us more about what you mean by "application
server".
Do you mean a separate HTTP server (which you might then
embed via mod_proxy into some other "compressing Apache"
as a front-end), or do you mean something inside the same
Apache, which is more like an Apache Handler, servlet
engine or CGI script?
In any case, mod_gzip is able to compress content that has
been produced by URL requests, be it static or dynamic con-
tent. So all you have to do is write the proper mod_gzip
inclusion rules to cover your content in both detection
phases (see
http://www.schroepl.net/projekte/mod_gzip/config.htm#filters
for details), and it should work then.
Regards, Michael
_______________________________________________
mod_gzip mailing list
mod_gzip@lists.over.net
http://lists
------_=_NextPart_001_01C38F28.E15E3FE0
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META content="MSHTML 5.50.4930.1700" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff size=2>Wow.
Very good explanation.</FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff size=2>The
application server is WebSphere 5.0 and it does have a module that gets loaded
in the configuration file.</FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff size=2>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? </FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial color=#0000ff size=2>I have
not specified <FONT color=#000000>"mod_gzip_item_include handler xxxxx" but it
seems to be working, how can this be? (From your response it seemed like the
handler directive would be required fro it to work)</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial size=2>Why does it only
work when chunks are enabled?</FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial
size=2>Etienne</FONT></SPAN></DIV>
<DIV><SPAN class=405531212-10102003><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> TOKILEY@aol.com
[mailto:TOKILEY@aol.com]<BR><B>Sent:</B> Thursday, October 09, 2003 10:43
PM<BR><B>To:</B> mod_gzip@lists.over.net<BR><B>Cc:</B>
TOKILEY@aol.com<BR><B>Subject:</B> Re: Antwort: RE: [Mod_gzip] Request
Handling<BR><BR></FONT></DIV><FONT face=arial,helvetica><FONT size=2><BR>Hi
Etienne...<BR>This is Kevin Kiley...<BR><BR>Someone mentioned this a few
messages back but since<BR>you still haven't said which 'Application Server'
you are <BR>using I thought I would also mention this...<BR><BR>...sometimes
the only way to get the output of an 'Application<BR>Server' compressed (
versus simple CGI backend ) is to make<BR>sure you have an 'include handler'
statement for this particular<BR>back-end Server in your mod_gzip config
file.<BR><BR>The way most 'Application Servers' work with Apache
follows<BR>the original 'Coldfusion' model.<BR><BR>The authors of the
Application Server usually write a small<BR>'mod_xxxxx' module of their own
for Apache and you usually<BR>have to install that into your Apache
Server.<BR><BR>What this module usually does is 'intercept' requests that
<BR>the Application Server is supposed to handle.<BR><BR>Almost all of these
"Application Server" modules do this in<BR>the same way the original
'ColdFusion' Apache module<BR>did it. They register a 'handler' name into the
request<BR>structure at one of the low-level Apache 'hooks' and then<BR>some
'higher-up' hook sees the 'handler' name and<BR>knows that this request is
meant for that particular<BR>Application Server.<BR><BR>Example: At the lowest
level hook possible... the<BR>mod_coldfusion module registers a 'handler'
name<BR>of 'coldfusion' on any request that Coldfusion is<BR>supposed to
handle.<BR><BR>The problem here is that once a higher level hook<BR>has 'seen'
this handler name and sent the transaction<BR>to the application server... it
usually does a 'Return ZERO'<BR>from the hook and in Apache code this means
that no<BR>other handlers get called for that transaction.<BR><BR>So... to
make a long, boring story short... it usually isn't<BR>enough to just enter
some URI inclusion 'rules' in <BR>the mod_gzip config and expect them to get
compressed<BR>if the request gets passed off to a 'back end'
Application<BR>Server.<BR><BR>You must ALSO have something like this ( which
is what<BR>works for ColdFusion... )<BR><BR>mod_gzip_item_include handler
coldfusion<BR><BR>Now what happens is that mod_gzip has a chance
to<BR>intercept the transactions that are going to be given<BR>a 'handler'
name of 'coldfusion' but ONLY if the URI<BR>matches some other 'regular' rule
that you have<BR>established for compressing output.<BR><BR>I know this all
sounds a little complicated but many <BR>people are not aware of this
'handler' scheme in Apache<BR>unless they use something like
ColdFusion.<BR><BR>It's a little obscure but it's the way Apache
works.<BR><BR>Any module that wanted to intercept transactions for<BR>back-end
servers using this 'handler name' scheme would<BR>have to have a similar
parameter so the NAME of the<BR>handler can be set at runtime.<BR><BR>If your
'Application Server' does NOT have it's own small<BR>'mod_xxx' module that
needs to be installed into Apache<BR>and/or does not follow this standard
'ColdFusion' approach<BR>I would be curious to know exactly how it DOES
work?<BR><BR>Later...<BR>Kevin<BR><BR>PS: The actual NAME of the handler that
is going to be<BR>registered inside Apache does NOT necessarily have<BR>to
match the name of the Application Server module that<BR>gets installed into
Apache.<BR><BR>In the case of ColdFusion... they just 'happen' to be
the<BR>same. The Application Server module you install is
called<BR>'mod_coldfusion' and the 'handler' name just happens to<BR>be
'coldfusion' as well ( lowercase ).<BR><BR>In truth... the ONLY way to be SURE
what the actual 'handler'<BR>name might be is to look at the source code for
the Application<BR>Server module and see exactly what 'handler' name they
are<BR>registering at runtime.<BR><BR>The name of the module could be
mod_super_back_end_server<BR>but the 'handler' name being registered could be
anything such<BR>as 'super_back_end_server_whatchamacallit'.<BR><BR>It isn't a
military secret so anyone familiar with the Application<BR>Server should know
what this 'handler' name is... but if things<BR>don't seem to work then the
first thing to verify is that you<BR>have the right HANDLER NAME for this
particular<BR>Application Server. Don't make any 'assumptions' about
it.<BR><BR><BR><BR><BR>In a message dated 10/9/2003 5:20:29 AM Central
Daylight Time, Michael.Schroepl@telekurs.de writes:<BR><BR><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"
TYPE="CITE"><BR><BR>Hi Etienne,<BR><BR><BR>> Is this functionality
currently in the mod_gzip module or<BR>> is that something that we would
have to request from you?<BR><BR>please tell us more about what you mean by
"application<BR>server".<BR>Do you mean a separate HTTP server (which you
might then<BR>embed via mod_proxy into some other "compressing Apache"<BR>as
a front-end), or do you mean something inside the same<BR>Apache, which is
more like an Apache Handler, servlet<BR>engine or CGI script?<BR><BR>In any
case, mod_gzip is able to compress content that has<BR>been produced by URL
requests, be it static or dynamic con-<BR>tent. So all you have to do is
write the proper mod_gzip<BR>inclusion rules to cover your content in both
detection<BR>phases (see<BR>
http://www.schroepl.net/projekte/mod_gzip/config.htm#filters<BR>for
details), and it should work then.<BR><BR>Regards,
Michael<BR><BR><BR>_______________________________________________<BR>mod_gzip
mailing
list<BR>mod_gzip@lists.over.net<BR>http://lists</BLOCKQUOTE><BR><BR></BLOCKQUOTE></FONT></FONT></BODY></HTML>
------_=_NextPart_001_01C38F28.E15E3FE0--
------=_NextPartTM-000-01e00589-a55b-4525-a8cf-3d96c7c07027--