mod_include revamp

[Brian Behlendorf <br...@hyperreal.org>]

Just a thought that occurred to me - be careful to avoid implementing
enhancements which will make sfio layering more difficult for 2.0.  

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org

Re: mod_include revamp

[Brian Behlendorf <br...@organic.com>]

My point exactly - if it is easier & cleaner to do this with 2.0, let's wait.

I'll send something related to 2.0 in another message...

	Brian

At 04:36 PM 7/22/97 -0700, Dean Gaudet wrote:
>If anything the layering makes this easier.  Granted it might require a
>rewrite of the heuristic, but that shouldn't be too difficult. 
>
>On Tue, 22 Jul 1997, Brian Behlendorf wrote:
>
>> Just a thought that occurred to me - be careful to avoid implementing
>> enhancements which will make sfio layering more difficult for 2.0.  

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org

Re: mod_include revamp

[Dean Gaudet <dg...@arctic.org>]

Duh, why didn't I think of running header_only subrequests. 

You have to run the requests for includes anyhow, that's how the current
code goes.  It'll just be running twice.

I don't think it'll break the text/x-parsed-html hacks for mod_cgi, since
you can always abort the first pass and start the real work immediately. 

Dean

On Tue, 22 Jul 1997, Alexei Kosut wrote:

> On Tue, 22 Jul 1997, Brian Behlendorf wrote:
> 
> > Just a thought that occurred to me - be careful to avoid implementing
> > enhancements which will make sfio layering more difficult for 2.0.  
> 
> Agreed. I think there's a simpler (possibly) way to do this than has been
> considered, that works without needing buffers or has anything to do with
> whether or not files are "static" or anything.
> 
> *) Have mod_include double-parse its input. The first pass, check for
>    length/date. The second, send it out. Straightforward, I think.
> 
> *) Whenever mod_include comes across an include (on the first pass), it
>    sets up a sub_request as normal. Except it sets
>    r->header_only. Combined with r->assbackwards, this should prevent
>    anything from being sent. Then run the subrequest. No data should come
>    out, but you should now have a request_rec that you can pull a content
>    type, content length, etag, whatever, out of. This way, any included
>    document can be scanned for the metadata, regardless of its actual
>    type.
> 
> Of course, it's entirely possible someone's already suggested something
> like this, and I just skipped that email. If so, I apologize.
> 
> But this approach makes sense to me. There are only two problems: You
> have to parse the include file twice, and you have to run the full
> request (well, part of it, anyway) for each include. That might be
> time-consuming.
> 
> But Brian is right that parsing twice doesn't work too well if the data
> it's parsing isn't static. For example, there are hacks that make mod_cgi
> output parseable for includes, and those would stop working. And it would
> be hard to rewrite mod_include into a filter for Apache 2.0. Of course,
> we could make two entry points into mod_include... a static-file parser
> that does the double parsing, and a filter version that does what it does
> now.
> 
> -- Alexei Kosut <ak...@organic.com>
> 
> 

Re: mod_include revamp

[Alexei Kosut <ak...@organic.com>]

On Tue, 22 Jul 1997, Brian Behlendorf wrote:

> Just a thought that occurred to me - be careful to avoid implementing
> enhancements which will make sfio layering more difficult for 2.0.  

Agreed. I think there's a simpler (possibly) way to do this than has been
considered, that works without needing buffers or has anything to do with
whether or not files are "static" or anything.

*) Have mod_include double-parse its input. The first pass, check for
   length/date. The second, send it out. Straightforward, I think.

*) Whenever mod_include comes across an include (on the first pass), it
   sets up a sub_request as normal. Except it sets
   r->header_only. Combined with r->assbackwards, this should prevent
   anything from being sent. Then run the subrequest. No data should come
   out, but you should now have a request_rec that you can pull a content
   type, content length, etag, whatever, out of. This way, any included
   document can be scanned for the metadata, regardless of its actual
   type.

Of course, it's entirely possible someone's already suggested something
like this, and I just skipped that email. If so, I apologize.

But this approach makes sense to me. There are only two problems: You
have to parse the include file twice, and you have to run the full
request (well, part of it, anyway) for each include. That might be
time-consuming.

But Brian is right that parsing twice doesn't work too well if the data
it's parsing isn't static. For example, there are hacks that make mod_cgi
output parseable for includes, and those would stop working. And it would
be hard to rewrite mod_include into a filter for Apache 2.0. Of course,
we could make two entry points into mod_include... a static-file parser
that does the double parsing, and a filter version that does what it does
now.

-- Alexei Kosut <ak...@organic.com>

Re: mod_include revamp

[Dean Gaudet <dg...@arctic.org>]

If anything the layering makes this easier.  Granted it might require a
rewrite of the heuristic, but that shouldn't be too difficult. 

Dean

On Tue, 22 Jul 1997, Brian Behlendorf wrote:

> Just a thought that occurred to me - be careful to avoid implementing
> enhancements which will make sfio layering more difficult for 2.0.  
> 
> 	Brian
> 
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> "Why not?" - TL           brian@organic.com - hyperreal.org - apache.org
>