Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3CAF240A.2080305@cnet.com>
Date: Sat, 06 Apr 2002 08:36:26 -0800
From: Brian Pane <brian.pane@cnet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: cvs commit httpd-2.0/modules/filters/mod_include.c
References: <OFC98C5ADE.A6DC452A-ON85256B92.00672E53@raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul Reder wrote:

>
> Sorry for the lack of timeliness on responding to this. Our mailserver 
> has been
>  about to be back up any minute now for a couple of days.
>
> The test case that I ran was even more brutal than what your test 
> module does.
> Basically I have a small piece of code that puts each byte in its own 
> bucket and
> each bucket in its own brigade.
>
> Brian's patch will not handle this case because there is no next 
> bucket to point
> tag_start_index at


The next bucket in this case is the brigade sentinel, which
is the same thing that send_parsed_content() would choose as
the next bucket to scan if we escaped from find_start_sequence()
with tag_start_index==NULL.

> I was a little vague in my description of the problem. Basically,
> if the <!--# tag occurs at the end of one brigade and the directive 
> starts at the
> beginning of the next brigade we have trouble. In my tests this was 
> causing a
> core dump which my patch fixed.
>
> I'm also surprised that the include virtual was failing since it 
> passed my tests. :(
> I'll double check those results to see if I missed something.
>
> Also, Brian, I do not see where the comment you removed was invalid. 
> Slen is only
> ever set to ctx->start_seq_len (which by default is 5 I believe). Slen 
> is never changed
> to be any number other than ctx->start_seq_len.
>
> I do not claim to have studied bndm enough to be certain, but it seems 
> to me that
> if the brigade has a single bucket with a single byte which hapens to 
> match within
> the pattern then you will end up incrementing ctx->bytes_parsed by 
> pos+slen (where
> slen == 5) when only one byte was processed.


bndm will only match on an instance of the complete pattern within
the current bucket.  If slen==5 and len==1, bndm won't find a match.
All the one-byte-at-a-time scanning code in find_start_sequence()
exists solely to catch the boundary cases where the pattern spans
two or more buckets--the cases that bndm won't detect.  So when bndm
finds a match, it's guaranteed that len >= slen.

If len==1 and bndm indicates that it's found a pattern, it can
only mean that the pattern has been changed from "<!--#" to some
single-byte token.  This case *is* possible, now that we support
the SSIStartTag directive.  But the logic for incrementing
ctx->bytes_parsed by pos+slen is still correct; pos+slen==1.

--Brian