Bug 17629: SSI, CGI, and mod_deflate

[Paul Querna <ch...@force-elite.com>]

http://issues.apache.org/bugzilla/show_bug.cgi?id=17629

basic flow inside httpd:
- handler sends output
- mod_include processes. data starts going down the filter chain.
- mod_include sees the need for a CGI (include/virtual/whatever).
- mod_include creates a subrequest. This subrequest uses the same filter
chain.
- If the subrequest is on a CGI, and that CGI sends a redirect
(Location:), mod_cgi{d} creates an internal redirect, which does *not*
use the same filter chain.  Any output from this redirect does not get
put into the same chain as the Main Request.
- Meanwhile, mod_deflate, which is on the main request's filter chain,
will gzip encode the content that goes through it.

The end result is mixed gzip and non-gzipped content.

I tried searching the mailing list quickly, but I didn't see any
reasoning why mod_cgi{d} uses an internal redirect for these cases.

The easy solution is to make mod_cgi{d} create a full subrequest, that
would therefore use the same filter chain, and therefore mod_deflate
would properly encode the content.

It seems that calling an internal redirect from anywhere in an output
filter is completely wrong.

Is there any reason not to switch mod_cgi{d} to use subrequests?  If no
one objects, I will do it in a couple days.

Thanks,

-Paul Querna

Re: Bug 17629: SSI, CGI, and mod_deflate

[Nick Kew <ni...@webthing.com>]

On Mon, 11 Oct 2004, [ISO-8859-15] Andr� Malo wrote:

> > It seems that calling an internal redirect from anywhere in an output
> > filter is completely wrong.
>
> Nope. The real problem is that it's a *redirect within a subrequest*.

Erm - it seems to me you're both right.  Surely the underlying problem -
of which both the above are instances - is an internal redirect too late
in the request processing cycle.  An internal redirect after anything
could possibly have been sent down the [output filter chain|wire] is
broken.

>	 The
> filterchain suddenly gets disconnected. What we need is kind of a glue filter
> which connects a subrequest (at "connection" level (a subrequest doesn't own
> a connection)) with the main one.

I'm struggling with how that should work, within the constraints of the
architecture we have.  I actually raised the question with Paul on IRC
in the hope that a solution would fall straight out of his "Capturing a
Subrequest".  But it seems we're all stuck on partial insights.

I'm provisionally +1 on Paul's proposed fix, but I wonder if it should be
conditional on ap_is_initial_req, to leave untouched the 'normal' CGI
case.

-- 
Nick Kew

Re: Bug 17629: SSI, CGI, and mod_deflate

[André Malo <nd...@perlig.de>]

* Paul Querna <ch...@force-elite.com> wrote:

> I tried searching the mailing list quickly, but I didn't see any
> reasoning why mod_cgi{d} uses an internal redirect for these cases.

because it's a different request with a different filter chain.

> The easy solution is to make mod_cgi{d} create a full subrequest, that
> would therefore use the same filter chain, and therefore mod_deflate
> would properly encode the content.

That solves the symptoms of this particular issue, but not the real problem.

> It seems that calling an internal redirect from anywhere in an output
> filter is completely wrong.

Nope. The real problem is that it's a *redirect within a subrequest*. The
filterchain suddenly gets disconnected. What we need is kind of a glue filter
which connects a subrequest (at "connection" level (a subrequest doesn't own
a connection)) with the main one.

I've tried to develop such a system for a long time, but ... I'm way to busy
:-(

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  #             André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;