httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Mod_include design
Date Wed, 25 Oct 2000 07:57:03 GMT

> Basically, as I understand it, mod_include needs to be fixed to handle SSI
> tags that can span multiple buckets or, in worst case, multiple brigades.
> The rest of the SSI processing (once the tag is obtained) seems to be ok.
> In order to do this I am converting mod_include to be a state machine with
> the state stored in the attached data structure in the filter ctx.

No, the goal for mod_include is to re-write it to make it work much better
than it did in 1.3.  Mod_include is a mess, and that includes all of the
tag handling.  We don't need to worry about multiple brigades, because
simply setting the tags aside and concat'ing the two brigade together will
suffice for a tag that spans brigades.  All we need is something that
allows a tag to span buckets, and the logic to set-aside the partial
brigades.

> HIGH LEVEL DESIGN:
>
> Buckets are parsed until the STARTING_SEQUENCE (or at least the first byte(s)) 
> are found. Once the STARTING_SEQUENCE is found, buckets are set aside into
> the ssi_brigade in ctx until the ENDING_SEQUENCE is found. The bucket containing
> the first byte of the STARTING_SEQUENCE is split at the first byte. All buckets
> up to the new split bucket are passed on.
> 
> If a partial STARTING_SEQUENCE is found at the end of a bucket, that bucket is split
> and set aside. If the bytes in the next bucket do not continue to match the
> STARTING_SEQUENCE the state machine is reset. The set aside buckets will be passed on.

What are you storing in the state machine?  If you are storing the
state of the starting or ending sequence, can't this be done without
storing the state in the ctx pointer.  I would rather see that work as a
static variable, much in the way it currently works.  The only thing that
would need to be added, is the logic to split a bucket at the beginning of
the tag, even if the full tag isn't in this bucket.

> >From here on, processing of the SSI tag proceeds as before.

I really dislike this statement.  The whole point of this was to try to
clean all of this up, not to hack something new into place.

I would like to see mod_include re-written, so that the handle_foo
functions actually return a brigade and that brigade is inserted into the
original brigade in place of the original tag.

> I'm sorry this has taken me so long, but I have been out of the 2.0 loop for
> a while and have had a lot to learn with all of the brigade and filter
> code. I have been picking up steam over the past couple of days and hope to
> have something working in the next couple of days. It would be very helpful if
> I were allowed to finish this without dribs and drabs of patches to get this
> piece or that piece fixed in the current version, it just means I need to manually
> merge the parts of these patches that still apply into the rewritten code to keep
> them in synch.

I was asked to make mod_include work this week, because we want to try to
get 2.0 running on locus.  That requires that we be able to at least serve
SSI pages.  This doesn't affect you negatively at all, because all of
these hacks that I am adding should be taken care of by your own
code.  Just copy mod_include off to the side before you do an update, then
copy it back afterwards. 

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message