Hi Dave,
On 23-Jan-06, at 2:43 PM, Michael Burns wrote:
Hi Dave,
On 23-Jan-06, at 10:16 AM, Dave Rolsky wrote:
Yeah, I think we're definitely seeing a bug. Calling $m-
>clear_buffer is supposed to unconditionally wipe all output
generated up to that point, _unless_ it's been flushed (in which
case it's already gone from Mason).
[..]
4. Send a patch to fix the bug.
5. Stay with 1.28 until Jon or I fix it and make a new release.
#4 would be great, but #5 is probably viable too ;)
I *think* I've fixed the bug. Question is, have I created any new
ones? <grin>
I altered the clear_buffer() method in Request.pm. After cycling
through the stack buffers and clearing them out, the request_buffer
wasn't being also cleaned out.
Here's the patch (against HTML-Mason-1.32):
Further to my patch submitted on January 23rd, I have noticed in my
development system that there are still some places where $m-
>clear_buffer() doesn't actually clear the buffer, even after
applying the patch I supplied.
Unfortunately I'm out of time this month to track the bug down
further and have just changed my code to not do that :-) but I wanted
to let you know.
It looks like my patch solves the problem *some* of the time, but
there are cases I've got where $m->clear_buffer called within a
component called within a component-with-content still causes pre-
existing output to be flushed ahead of an $m->clear_buffer call
(rendering subsequent $m->abort(SERVER_ERROR) or $m->redirect calls
unusable / erroneous).
I've double checked my handler configuration, and I've got autoflush
completely disabled (including 'enable_autoflush'=>0). I can provide
my full handler configuration if that's helpful ...
I'm not sure where the output is coming from, but I've done some
debugging and can see it in the $m request object ... just not sure
*why* it's not all being cleared out :-) maybe you have a better clue
than I.
I'll try to take another look at it again in a week or two, but I
just wanted to report it in the mean time ...
Regards,
-Michael
On 23-Jan-06, at 2:43 PM, Michael Burns wrote:
Hi Dave,
On 23-Jan-06, at 10:16 AM, Dave Rolsky wrote:
Yeah, I think we're definitely seeing a bug. Calling $m-
>clear_buffer is supposed to unconditionally wipe all output
generated up to that point, _unless_ it's been flushed (in which
case it's already gone from Mason).
[..]
4. Send a patch to fix the bug.
5. Stay with 1.28 until Jon or I fix it and make a new release.
#4 would be great, but #5 is probably viable too ;)
I *think* I've fixed the bug. Question is, have I created any new
ones? <grin>
I altered the clear_buffer() method in Request.pm. After cycling
through the stack buffers and clearing them out, the request_buffer
wasn't being also cleaned out.
Here's the patch (against HTML-Mason-1.32):
--- HTML-Mason-1.32.orig/lib/HTML/Mason/Request.pm 2006-01-03
11:01:00.000000000 -0700
+++ HTML-Mason-1.32/lib/HTML/Mason/Request.pm 2006-01-23
13:31:34.000000000 -0700
@@ -1338,6 +1338,10 @@
my $bufref = $frame->[STACK_BUFFER];
$$bufref = '';
}
+
+ # Also clear any accumulated output in the request buffer.
+ #
+ $self->{request_buffer} = '';
}
sub flush_buffer
I did a make && make test sequence, and all the tests passed ... I
suppose that's a good sign. Also all my personal test cases (let me
know if you'd like any to include in the test suite?) that expose
the bug work now as expected.
All calls to $m->clear_and_abort() and $m->redirect(), for example,
properly work as expected (whereas before, output in the buffer
caused corrupted headers/etc. to the browser rendering those
methods unusable, if called from a component called from within a
component-with-content).
Let me know if you have any feedback, and also if you have a
feeling for if/when this might make it into an official release ...
Thanks again for your time & assistance,
-Michael
On 23-Jan-06, at 10:16 AM, Dave Rolsky wrote:
On Mon, 23 Jan 2006, Michael Burns wrote:
In any case, this certainly doesn't seem to mesh with the most
current documentation I could find about changes to $m-
>clear_buffer. From the changelog for 1.29_01, 1.29_02, and 1.30,
the statement is:
1.29_01 January 25, 2005
[ INCOMPATIBLE CHANGES ]
- ** The behaviors of $m->flush_buffer and $m->clear_buffer have
been
simplified. $m->flush_buffer only acts on the top-level output
buffer;
$m->clear_buffer clears all output buffers. Task id #554.
This doesn't seem to represent what is happening ... at least for
component-with-content calls.
Yeah, I think we're definitely seeing a bug. Calling $m-
>clear_buffer is supposed to unconditionally wipe all output
generated up to that point, _unless_ it's been flushed (in which
case it's already gone from Mason).
1. Understand better how the output stack works to suggest a fix
to the group so I can run my web app under Mason 1.32 -- my
preferred solution :-)
2. Keep running Mason 1.28
3. Remove/rework all component-with-content calls in my web app
to ensure nothing relies on a $m->clear_buffer call, and then use
Mason 1.32 (probably what I'll do if I can't do #1).
4. Send a patch to fix the bug.
5. Stay with 1.28 until Jon or I fix it and make a new release.
#4 would be great, but #5 is probably viable too ;)
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________________
Michael Burns
Cosbit Technologies
403-701-2672 / [EMAIL PROTECTED]
AIM: cmikeburns
MSN: cmikeburns
_______________________________________________________
Box 2173, Station M • Calgary, Alberta, Canada • T2P 2M4
http://cosbit.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
!DSPAM:43d54e38216129180514722!
_______________________________________________________
Michael Burns
Cosbit Technologies
403-701-2672 / [EMAIL PROTECTED]
AIM: cmikeburns
MSN: cmikeburns
_______________________________________________________
Box 2173, Station M • Calgary, Alberta, Canada • T2P 2M4
http://cosbit.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
