httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: include module.
Date Thu, 14 Sep 2000 02:26:58 GMT
Ah. That is a very good scenario.

Personally, I see a subrequest as a pretty heavy operation. Any content that
has been generated really can/should go out at that point, then the
subrequest gets run.

But all that said: it would be fine to add a new "subrequest" bucket type
and mechanisms for using it. **BUT** we cannot break the old subrequest
system. That must continue to exist in its present form. Existing modules
should not have to extensively rewrite how they use subrequests (in the same
way that they do not have to alter their use of ap_r*()).

This does imply that if a content-generator or content-filter is holding
some pending (outbound) content in a brigade, then it must flush it before
invoking the subrequest.

The flush won't apply to existing code since they use ap_r*() which already
passes the content down the filter stack.

Note that if a filter is holding up content (from an ap_r*()), then the
content-generator performs a subrequest, all the content *will* be ordered
properly. (since it arrives in the correct order at the filter that is
holding onto it for a while)

The problem only arises when a handler/filter mixes brigades (as a delaying
mechanism for sending content) and subrequests (which also send content).

Summary: a new bucket type is fine, but the existing mechanism, interface,
and other subrequest stuff should not change, nor require existing modules
to change.

Cheers,
-g

On Wed, Sep 13, 2000 at 08:37:26PM -0500, William A. Rowe, Jr. wrote:
> 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.
> 
> Bill
> 
> > -----Original Message-----
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Tuesday, September 12, 2000 7:15 PM
> > To: new-httpd@apache.org
> > 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:
> > 
> > foo.bar:
> > 
> > "THIS IS A TEST"
> > 
> > and foo.shtml:
> > 
> > "This is the start of a test <!--#include virtual="foo.bar" -->  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.
> > CHUNK
> > CORE
> > 
> > In the interest of performance, we don't call ap_pass_brigade 
> > before the
> > sub_request.  The sub_request has a filter stack:
> > 
> > INCLUDES
> > CHUNK
> > CORE
> > 
> > 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                        	rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > --------------------------------------------------------------
> > -----------------
> > 
> > 

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message