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
