httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject include module.
Date Wed, 13 Sep 2000 00:14:51 GMT

I basically have mod_include working as a filter.  It is absolutely,
completely ugly, but I expect to commit it later tonight.  One of the
problems, is that we have to call ap_pass_brigade all over the place.  The
problem is that we are using sub_requests.  

Here's the issue, how I have solved it, and why it can never work well, as
well as a potential solution:

Mod_include does a lot of stuff using sub_requests, I ran into this trying
to use "include virtual".  The way I have modified mod_include, we search
for <!--# and -->  The buckets are split so that we have one or more
buckets that compose the full SSI tag.  We then parse those buckets to
create the data that was represented by the tags.  That's all fine and
good, and it works.  Now, if when parsing those tags, we need to generate
a sub-request, well the sub-request uses the same filter stack, and
outputs to the same socket.  The problem is that we haven't sent any data
down the filter from mod_include yet!

So, if we have to files:


and foo.shtml:

"This is the start of a test <!--#include virtual="" -->  end"

We will always get:

"THIS IS A TEST This is the start of a test end"

I have solved the problem with a hack, by passing the first part of the
brigade down the filter stack before doing anything that might cause a
sub-request.  This is incredibly ugly IMNSHO.

Just so I am absolutely clear before I propose any cleaner solutions, the
problem is:

INCLUDES    <-- Generates some data, and a sub_request, then more data.

In the interest of performance, we don't call ap_pass_brigade before the
sub_request.  The sub_request has a filter stack:


At the end of the sub-request, the data is sent down the stack, and
control returns back to the main request.  At this point, the main request
sends data down the filter stack.


I have two options for clean solutions, they both require that
sub-requests are re-implemented.

1)  ap_run_sub_req can return a bucket_brigade.  This bucket brigade is
the response of the sub request.  The main request then has to insert the
sub-request in the main bucket-brigade.  This means that sub-requests
automatically get run through all of the main-line's filters that are
beneath the filter making the sub-request.  Anything else is the
responsability of the sub-request itself.

2)  ap_run_sub_req creates a URI_BUCKET.  This bucket's read function runs
the request and returns the data from it.  The main request just has to
insert the URI_BUCKET in the bucket brigade.

I will be committing the ugly mod_include later tonight, after I have
tested it a bit more.  This will remove the final ugly IOL hack that is
left in the code.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message