Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030516104835.018114b0@pop3.rowe-clan.net>
Date: Fri, 16 May 2003 10:54:40 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c
Cc: dev@httpd.apache.org
In-Reply-To: <n2m-g.1v9x88ec20lq8$ndparker@news.perlig.de>
References: <20030516141141.7060.qmail@icarus.apache.org>
 <5.2.0.9.2.20030516094827.0378c570@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 10:17 AM 5/16/2003, Andr=E9 Malo wrote:

>Darn. Then we need an alternative solution. (Actually we need a clear
>distinction between main filter chain and subreq filter chain, but that
>would really break some compatibilities).
>The current code produces under some circumstances garbage (see
><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D17629>).

The problem is that we have;

network
 \- transport (e.g. ssl)
     \- protocol (e.g. http, headers, etc)
         \- response (e.g. deflate, charset, etc)
             \- content/body

We really should link subrequests back to the response chain, not at
the protocol chain, and never allow modules to affect the response filter=20
or above on subrequest invocations.

But before we go off that deflate isn't inserted at the right point, I also
believe deflate needs to be intellegent.  If the subrequest turns out to
be deflated (e.g. a cgi with deflation of it's own) it would be really slick
if deflate 'undeflated' that subrequest content before adding it to the
main request stream.

>Here is a repost from an earlier mail about filter chain redesigning=
 issues:
>
>=3D=3D=3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>The filter system should be considered for redesign anyway in a form that
>the subreq_core filter acts as data link between the subrequest and the
>caller. Given that figure:
>
>main stream
>---------------------------,----------->
>                          /
>subreq stream            /
>------------------------x subreq_core_filter
>
>The subrequests should get their own filter stack. And the subreq core
>filter is the bottommost (!) within the subreq stack and redirects the data
>back to the main stream (filtering out the EOS buckets).
>At the moment any changes in the filter stack from within a subreq will
>have effect on the main filter stack, which is not so really cool.
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>8=3D=3D=3D=3D=3D
>
>Which should perhaps be considered for 2.1 series in order to handle the
>filter stack cleanly.
>
>However, I've currently no real idea how to solve the bugfix otherwise :-(
>Any opinions?

The problem with two stacks is speed.  You have to throw all the buckets
across the gap back to the main filter stack, which wastes time for all
well-written modules, but saves you from the clunky module.

Bill