[Mod_gzip] handlers and missing directories
mod_gzip@lists.over.net
mod_gzip@lists.over.net
Mon, 31 Mar 2003 17:44:18 EST
--part1_1de.5bc90bc.2bba1ec2_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
> Gareth wrote...
>
> I think you mis-understand.
>There is no error.
>The handler for the entire site is Mason.
> Mason handles the requests that are for non-existent files by passing
> them up the dhandler chain for the path.
A request for a (specific) non-existent URI ( Universal Resource Inidicator )
is, in HTTP protocol terms, always considered an 'error'.
The 'normal' (HTTP) response would be '404 Not Found'.
If something is stepping in to 'fix the error' then that's
as fine as frog's hair but from a protocol standpoint the
'error' has already happened.
> /test/x/mouse.html would check for the existence of the file.
> When it didn't find it - it passes it off to /test/x/dhandler.
> If that isn't found - it passes it to /test/dhandler - if not that then
/dhandler.
What do you mean by 'passes off'?
Who or what is 're-directing' things and how is it doing it?
It's obviously re-writing the URI at that point and submitting
'another request' into the Server engine but is it doing an
'internal redirect' or issuing a full-blow sub-request?
This was what I wanted to know. HOW is it 'passing off'
the request in order to recover from the initial 'Not found'
error?
Or does some back-end CGI just keep re-parsing the URI
and checking for files until it gets a 'hit'?
> dhandler then does whatever it sees fit - generates content as per usual.
I understand.
What does that 'final response' look like?
Drop into telnet and request one of these non-existent
documents and then cut-paste what 'dhandler' sends
back so we can see if it's really a '200 response' or
something other than '200'.
> This isn't much different from a normal request to a Mason
> server - since the request would be handled by a bunch of autohandlers
> if the file was found anyway.
>
> The point being - there is no error - Mason handles the request itself.
I would describe the scenario more like 'Mason is handling the
error' since a file was actually 'Not found' but that's just
semantics. To each his own.
> As far as your next part goes - I agree, the mod_gzip debug would be useful
here.
I don't think you need to run the 'debug' version(s) of mod_gzip.
Those versions will end up striking more information than you
ever wanted to know about what's going on into your Apache log
and I don't think the issue requires it.
I was simply referrring to the standard 'mod_gzip log' entries which
are just a few bytes of information that get tacked onto the ends
of your regular Apace log entries.
> I turned apache logging up to info - but that didn't help.
Changing the Apache log level does nothing. You have to
use the 'mod_gzip' log directives and add what are
Apache calls 'notes' to the end of the common log entries
using the generic Apache 'CustomLog' directives.
> Tomorrow morning I'll look into how to make mod_gzip log more info - I'm
> guessing it's in the documentation or FAQ's somewhere - either way - easily
done.
> I'll repost to the list in 12 hours or so.
> Thanks for your time and effort.
> Gareth
It's a no brainer... for the full set of mod_gzip log info
just add this to your http.conf file...
LogFormat "%h %l %u %t \"%r\" %>s %b mod_gzip: %{mod_gzip_result}n
In:%{mod_gzip_input_size}n
Out:%{mod_gzip_output_size}n:%{mod_gzip_compression_ratio}npct."
common_with_mod_gzip_info2LogFormat "%h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\" mod_gzip:
%{mod_gzip_compression_ratio}npct." full_plus_gzip
CustomLog /var/log/apache/usenet.log common_with_mod_gzip_info2
If all you want is the 'result' string ( DECLINED:REASON, etc. )
then all you need is this...
LogFormat "%h %l %u %t \"%r\" %>s %b mod_gzip: %{mod_gzip_result}n
CustomLog /var/log/apache/usenet.log common_with_mod_gzip_info2
--part1_1de.5bc90bc.2bba1ec2_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=
=3D"Arial" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">> Gareth wrote...<BR>
><BR>
> I think you mis-understand.</FONT><FONT COLOR=3D"#000000" style=3D"BAC=
KGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=
=3D"0"><BR>
></FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=
=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">There is no error.</FON=
T><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMI=
LY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
></FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=
=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">The handler for the ent=
ire site is Mason.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR:=
#ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">> Mason handles the requ=
ests that are for non-existent files by passing <BR>
> them up the dhandler chain for the path.<BR>
<BR>
A request for a (specific) non-existent URI ( Universal Resource Inidicator=20=
)<BR>
is, in HTTP protocol terms, always considered an 'error'.<BR>
<BR>
The 'normal' (HTTP) response would be '404 Not Found'.<BR>
<BR>
If something is stepping in to 'fix the error' then that's<BR>
as fine as frog's hair but from a protocol standpoint the<BR>
'error' has already happened.<BR>
<BR>
> /test/x/mouse.html would check for the existence of the file.</FONT><FO=
NT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=
=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">> When it didn't find it=
- it passes it off to /test/x/dhandler.</FONT><FONT COLOR=3D"#000000" styl=
e=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma=
" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">> If that isn't found -=20=
it passes it to /test/dhandler - if not that then /dhandler.<BR>
<BR>
What do you mean by 'passes off'?<BR>
<BR>
Who or what is 're-directing' things and how is it doing it?<BR>
<BR>
It's obviously re-writing the URI at that point and submitting<BR>
'another request' into the Server engine but is it doing an<BR>
'internal redirect' or issuing a full-blow sub-request?<BR>
This was what I wanted to know. HOW is it 'passing off'<BR>
the request in order to recover from the initial 'Not found'<BR>
error?<BR>
<BR>
Or does some back-end CGI just keep re-parsing the URI<BR>
and checking for files until it gets a 'hit'?</FONT><FONT COLOR=3D"#000000"=
style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"T=
ahoma" LANG=3D"0"><BR>
<BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">> dhandler then does wha=
tever it sees fit - generates content as per usual.<BR>
<BR>
I understand.<BR>
<BR>
What does that 'final response' look like?<BR>
<BR>
Drop into telnet and request one of these non-existent<BR>
documents and then cut-paste what 'dhandler' sends<BR>
back so we can see if it's really a '200 response' or<BR>
something other than '200'.<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
> </FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZ=
E=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">This isn't much differ=
ent from a normal request to a Mason <BR>
> server - since the request would be handled by a bunch of autohandlers=20=
<BR>
> if the file was found anyway.</FONT><FONT COLOR=3D"#000000" style=3D"B=
ACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=
=3D"0"><BR>
><BR>
> </FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZ=
E=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">The point being - ther=
e is no error - Mason handles the request itself.</FONT><FONT COLOR=3D"#000=
000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=
=3D"Tahoma" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
I would describe the scenario more like 'Mason is handling the<BR>
error' since a file was actually 'Not found' but that's just <BR>
semantics. To each his own.<BR>
<BR>
> As far as your next part goes - I agree, the mod_gzip debug would be us=
eful here.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff=
" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
I don't think you need to run the 'debug' version(s) of mod_gzip.<BR>
Those versions will end up striking more information than you<BR>
ever wanted to know about what's going on into your Apache log<BR>
and I don't think the issue requires it.<BR>
<BR>
I was simply referrring to the standard 'mod_gzip log' entries which<BR>
are just a few bytes of information that get tacked onto the ends<BR>
of your regular Apace log entries.<BR>
<BR>
> I turned apache logging up to info - but that didn't help.</FONT><FONT=20=
COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3 FAMILY=3D"SA=
NSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
Changing the Apache log level does nothing. You have to<BR>
use the 'mod_gzip' log directives and add what are <BR>
Apache calls 'notes' to the end of the common log entries<BR>
using the generic Apache 'CustomLog' directives.<BR>
<BR>
> Tomorrow morning I'll look into how to make mod_gzip log more info - I'=
m <BR>
> guessing it's in the documentation or FAQ's somewhere - either way - ea=
sily done.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff=
" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
> </FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZ=
E=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">I'll repost to the lis=
t in 12 hours or so.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLO=
R: #ffffff" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
> </FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZ=
E=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">Thanks for your time a=
nd effort.</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff=
" SIZE=3D3 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
> </FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZ=
E=3D2 FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0">Gareth<BR>
<BR>
It's a no brainer... for the full set of mod_gzip log info <BR>
just add this to your http.conf file...<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">LogFormat "%h %l %u %t \"%r\=
" %>s %b mod_gzip: %{mod_gzip_result}n In:%{mod_gzip_input_size}n Out:%{m=
od_gzip_output_size}n:%{mod_gzip_compression_ratio}npct." common_with_mod_gz=
ip_info2LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Age=
nt}i\" mod_gzip: %{mod_gzip_compression_ratio}npct." full_plus_gzip<BR>
<BR>
CustomLog /var/log/apache/usenet.log common_with_mod_gzip_info2<BR>
<BR>
</FONT><FONT COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
If all you want is the 'result' string ( DECLINED:REASON, etc. ) <BR>
then all you need is this...<BR>
<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2=
FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">LogFormat "%h %l %u %t \"%r\=
" %>s %b mod_gzip: %{mod_gzip_result}n <BR>
CustomLog /var/log/apache/usenet.log common_with_mod_gzip_info2</FONT><FONT=20=
COLOR=3D"#808080" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SA=
NSSERIF" FACE=3D"Tahoma" LANG=3D"0"><BR>
</FONT></HTML>
--part1_1de.5bc90bc.2bba1ec2_boundary--