httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Reder" <>
Subject Re: cvs commit httpd-2.0/modules/filters/mod_include.c
Date Fri, 05 Apr 2002 19:19:48 GMT
Sorry for the lack of timeliness on responding to this. Our mailserver has 
 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 
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 
tag_start_index at. I was a little vague in my description of the problem. 
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.

That is to say, len == 1, so it will enter the "if (len)" conditional 
block around line 472.
Bndm can match the pattern and return pos = 0, so it enters the (pos != 
len) conditional
block. At the end of this block it increments ctx->bytes_parsed by 
pos+slen even
though it only processed one byte. The previous bytes will have already 
accounted for during runs through find_start_sequence for previous 

Where am I confused?

Sorry again for the delay in responding.

Paul J. Reder
View raw message