httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: subrequest filtering (yet again)
Date Thu, 21 Sep 2000 18:56:24 GMT writes:

> A couple of things.  Tony and I have had multiple discussions of sub
> request filtering, and we still haven't come up with a great decision,
> which is why we haven't posted anything before.  I will try to summarize
> what we keep going back and forth about.
> Our original hypothesis was that sub requests should just inherit the
> connection based filters, and all content filters should be re-generated
> based on the actual content.
> But, A sub request is essentially a part of this current request, so the
> output of the sub request really has to go through the same filters as the
> main-line request.
> Take for example mod_include.  If we include a file through a #include
> virtual directive, we use a sub-request.  Well, all of the data in that
> sub-request is actually a part of the original request.  What if we have a
> gzip filter setup for the original request, the sub request has to go
> through the same gzip filter in the correct order.

O.k...  I see.

> The best we have really come up with so far, is that we the sub-request
> output should go to the next filter in the stack.  At least I am pretty
> sure that was what we decided.

That makes a lot of sense.

Now sometimes the filters defined for the subrequest will clash with
the filters defined for the original request.  What if both the
original request and the subrequest have a gzip filter defined?
Garbage comes out.  What if both have some character set translation
defined?  Garbage comes out.

> As far as removing filters.  We need that ability.  I am really hoping to
> get back into the Apache coding soon.  I know I keep saying that.  One of
> my first projects will be to just allow people to remove a filter from the
> filter stack.
> I think the big thing that is missing, is that a sub-request does want to
> inherit some of the filters.  I really think we need to code this one way
> and see if it works, because right now, we are really just flailing
> blindly at what we think the design should be, based on logic, not
> experience.  As we all know, sometimes the best design just doesn't take
> the smallest detail into account.

Assume the hopefully-normal case where the filters for the request and
the filters for the subrequest don't clash:

  When we create a subrequest, it inherits the full set of filters from
  the request.  This is appropriate (I think) if the subrequest was
  initiated by a handler (non-filter).

  If the subrequest was initiated by a filter, perhaps the filter could
  set subrequest->output_filters to f->next after creating the
  subrequest but before running it.  I think that this would cause
  subsequent filters for the original request to be executed at the
  right time.  We haven't gotten to the insert filters hook (sorry!) for
  the subrequest yet so we still have time to add the filters
  appropriate to the subrequest.

As for the hopefully-rare case where the filters for the request and
the filters for the subrequest clash:

  I guess your comment about the need to remove filters is intended to
  cover this?

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message