httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: mod_include revamp
Date Tue, 22 Jul 1997 23:48:22 GMT
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. 


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 <>

View raw message