On Mon, 21 Jul 2003, Ron Park wrote:
> Ok, looks like we had the wrong patch (I think we had the
> first attempt that failed two existing cases); with the
> correct (lastest) patch, it works on our site. :)
>
> Thanks all, especially Cliff!
/me commits the patch.
/me redirects the "especially" to
t: Monday, July 21, 2003 5:26 PM
> To: [EMAIL PROTECTED]
> Cc: Ron Park
> Subject: RE: Two mod_include problems
>
>
>
>
> It actually had:
> SetOutputFilter BUCKETEER
>
> But I changed it to:
> AddOutputFilter BUCKETEER;INCLUDES .shtml
>
> And it still passes.
>
> --Cliff
>
It actually had:
SetOutputFilter BUCKETEER
But I changed it to:
AddOutputFilter BUCKETEER;INCLUDES .shtml
And it still passes.
--Cliff
Does the test case have the following turned on?
AddOutputFilter BUCKETEER;INCLUDES .shtml
Ron
> -Original Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2003 4:55 PM
> To: [EMAIL PROTECTED]
> Cc: Ron Park
> Subject: RE: Two mo
On Mon, 21 Jul 2003, Cliff Woolley wrote:
> > Ok, here's a small test file that shows that that
> > mod_include patch is not working properly (using
> > mod_bucketeer notation, all one line):
> >
> > Before If Anything^FNothingSomethingElseAfter if
I just added this exact test to httpd-test. But
On Mon, 21 Jul 2003, Ron Park wrote:
> Ok, here's a small test file that shows that that
> mod_include patch is not working properly (using
> mod_bucketeer notation, all one line):
>
> Before If Anything^FNothingSomethingElseAfter if
Okay, I'm committing that to the httpd-test suite right now. T
ned)
With the patch, it seems to throw away too much!
SomethingElseAfter if
:(
Ron
> -Original Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2003 2:31 PM
> To: Ron Park
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Two mod_includ
On Mon, 21 Jul 2003, Ron Park wrote:
> Yes, this is the patch we tried.
It passes my tests. You'll have to give me some more specific things to
try to see it fail.
Andre also brought up a point about different SSIStartTag settings, like
"", with a sequence like "--^P--" (mod_bucketeer notat
Yes, this is the patch we tried.
> -Original Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2003 1:25 PM
> To: [EMAIL PROTECTED]; Ron Park
> Subject: RE: Two mod_include problems
>
>
> On Mon, 21 Jul 2003, Ron Park wrote:
On Mon, 21 Jul 2003, Ron Park wrote:
> Unfortunately, it seems your patch from 07/12/03 does
> not work on our pages. :( We haven't yet tracked down
> *how* it's not working though. More info to follow.
Which patch, specifically? The one I'm looking at right now is Andre's
patch that has the f
ginal Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 21, 2003 11:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Two mod_include problems
>
>
> On Mon, 21 Jul 2003, André Malo wrote:
>
> > Well, this is going to fall off the radar. What do
On Mon, 21 Jul 2003, André Malo wrote:
> Well, this is going to fall off the radar. What do we do now? Any other
> reviews/testers available?
Thanks for the reminder... test results from me as soon as I get in to the
office in about an hour. Other testers would be much appreciated though.
1-2 se
* Cliff Woolley wrote:
> On Sat, 12 Jul 2003, [ISO-8859-1] André Malo wrote:
>
>> I've tried several times... the patch continues to fail on test 35 and 54
>> here. Finally I went back to our initial patch and tried to figure out the
>> insufficient test. The attached resulting patch passes all 5
On Sat, 12 Jul 2003, [ISO-8859-1] André Malo wrote:
> > I'm trying to prevent potential future confusion. Does that
> > make sense?
>
> yes, it does. Convinced :)
+1 here also.
On Sat, 12 Jul 2003, [ISO-8859-1] André Malo wrote:
> I've tried several times... the patch continues to fail on test 35 and 54
> here. Finally I went back to our initial patch and tried to figure out the
> insufficient test. The attached resulting patch passes all 54 tests on my
> machine. Other
* Cliff Woolley wrote:
> Please try the attached patch and see if it passes your tests. It also
> adds a lot of assertions which we needed to help debug our patch, but I'll
> remove those before committing.
I've tried several times... the patch continues to fail on test 35 and 54
here. Finally I
* Paul J. Reder wrote:
> Its mostly a matter of pedantics. :)
Sure ;-)
> Logically the reset should be linked to the actual action
> of passing the bytes. In your hypothetical else there are
> no bytes, so *all* existing (i.e. 0) bytes have been sent.
...
> I'm trying to prevent potential future
On Fri, 11 Jul 2003, Ronald K Park, Jr wrote:
> Ok, I've finally created a simple example. Unfortunately, I'm
> working from home today and having trouble getting the file on
> my local machine to send as an attachment.
Please try the attached patch and see if it passes your tests. It also
adds
On Fri, 11 Jul 2003, Ronald K Park, Jr wrote:
> Ok, I've finally created a simple example.
I came up with an example case last night as well... it's in the
httpd-test perl-framework now under modules/include.t (test #53). It
actually revealed that the patch Andre and I came up with for case #2 w
Ok, I've finally created a simple example. Unfortunately, I'm
working from home today and having trouble getting the file on
my local machine to send as an attachment.
You need to make sure includes are turned on with the following:
AddOutputFilter BUCKETEER;INCLUDES .html
Simple create a file i
Its mostly a matter of pedantics. :)
Logically the reset should be linked to the actual action
of passing the bytes. In your hypothetical else there are
no bytes, so *all* existing (i.e. 0) bytes have been sent.
The problem I see with that is that if code is added later,
involving setaside bytes o
Its mostly a matter of pedantics. :)
Logically the reset should be linked to the actual action
of passing the bytes. In your hypothetical else there are
no bytes, so *all* existing (i.e. 0) bytes have been sent.
The problem I see with that is that if code is added later,
involving setaside bytes o
* Paul J. Reder wrote:
> With the other changes, the way I read the patch was as:
>
> if (ctx->state == PRE_HEAD) {
> if (!empty) {
> pass
> /* reset deleted from here */
> }
> reset /* reset added here */
> }
yep... I meant, one c
We tried using mod_bucketeer to recreate our problems
but all attempts failed. :(
Ron
> -Original Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 10, 2003 4:45 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Two mod_include proble
On Thu, 10 Jul 2003, Ron Park wrote:
> We're trying to come up with nice simple test cases to
> show the problems (all ours involve a proprietary module
> and mod_proxy but they should be recreatable with some
> carefully crafted file sizes).
The file sizes don't even need to be carefully crafted
With the other changes, the way I read the patch was as:
if (ctx->state == PRE_HEAD) {
if (!empty) {
pass
/* reset deleted from here */
}
reset /* reset added here */
}
else if (ctx->state == PARSED) { /* Invalid internal conditi
We'll give this patch a shot.
Ron
> -Original Message-
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2003 10:27 PM
> To: Ron Park
> Cc: [EMAIL PROTECTED]
> Subject: Re: Two mod_include problems
>
>
> yOn Wed, 9 Jul 2
ré Malo [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2003 6:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Two mod_include problems
>
>
> * Ron Park wrote:
>
> > At line 438 of mod_include, we see the code is set up to handle
> > this 'left over partial
* Paul J. Reder wrote:
> The "ctx->bytes_parsed = 0;" *should* be inside the if block.
> bytes_parsed should only be reset to 0 if the parsed bytes are
> passed on (via ap_pass_brigade()). bytes_parsed is supposed to
> indicate the number of bytes in the currently held brigade
> which have been pa
The "ctx->bytes_parsed = 0;" *should* be inside the if block.
bytes_parsed should only be reset to 0 if the parsed bytes are
passed on (via ap_pass_brigade()). bytes_parsed is supposed to
indicate the number of bytes in the currently held brigade
which have been parsed. If it exceeds BYTE_COUNT_THR
yOn Wed, 9 Jul 2003, Ron Park wrote:
> This problem revolves around the use of 'if' 'else' and 'elseif'.
> Originally, we thought the problem was related to
> but later we found an troublesome that lead to
> us finding the real culprit.
Andre and I counter-propose the following patch for this p
* Ron Park wrote:
> At line 438 of mod_include, we see the code is set up to handle
> this 'left over partial match' and it increments the temporary
> buffer pointer, c, by 2 as it walks past the '--' at the start
> of this bucket. So it (as far as I could determine) adds the
> left over ' and co
On Wed, 9 Jul 2003, Ron Park wrote:
> We have run across two problems in mod_include that were
> corrupting our pages and would like to share our patches.
Doh. :( Thanks for the in-depth comments and patch.. I'll review
tonight. The more eyes the better, though...
Thanks,
--Cliff
Oops, I apologize.
I accidently included another minor enhancement in this patch.
At line 3141 of the code, there was some code to call the
apr_brigade_cleanup method if the context's ssi_tag_brigade
is not empty... but then there was another exact same call
to apr_brigade_cleanup like 20 lines l
34 matches
Mail list logo
