httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: include module.
Date Thu, 14 Sep 2000 01:37:26 GMT
Why is this ugly?

main request:

This is the start of a test... could be slow, so hang on!
<!--#include virtual="slow.cgi" -->
Thanks for waiting end

The author expects the first message to -pop- as the user starts,
and slow.cgi can chug along.  When it finishes, the author expected
the message to let the user know it's done.

Of course fragments must be cast out to the client as they are ready.


> -----Original Message-----
> From: []
> Sent: Tuesday, September 12, 2000 7:15 PM
> To:
> Subject: include module.
> 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.
> Solutions:
> 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 
> ______________________________________________________________
> _________________
> Ryan Bloom               
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------

View raw message