Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 62425 invoked from network); 2 Feb 2008 12:31:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Feb 2008 12:31:10 -0000 Received: (qmail 77947 invoked by uid 500); 2 Feb 2008 12:31:00 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 77909 invoked by uid 500); 2 Feb 2008 12:31:00 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 77888 invoked by uid 99); 2 Feb 2008 12:30:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Feb 2008 04:30:59 -0800 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Feb 2008 12:30:30 +0000 Received: from [192.168.0.125] (unknown [212.76.37.214]) by smtp.mxes.net (Postfix) with ESMTP id 3A48CD05A2 for ; Sat, 2 Feb 2008 07:30:36 -0500 (EST) Message-ID: <47A462F9.10503@apache.org> Date: Sat, 02 Feb 2008 13:32:57 +0100 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.9 (X11/20070801) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Run latest from trunk References: <47A2C4B8.2070404@otego.com> <47A2D93D.7090204@apache.org> <47A366DC.9030205@apache.org> <47A385A4.4000703@apache.org> In-Reply-To: <47A385A4.4000703@apache.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Grzegorz Kossakowski pisze: > Grzegorz Kossakowski pisze: >> Felix Knecht pisze: >> I can confirm now that I see this problem locally. By mistake, I was testing a copy without this bug >> fix before committing so I didn't spot it. >> >> I'm just having a look at this. >> >> Sorry for breaking your work at the end of the week! :-( > > I have looked at this and found the cause for this bug. Class > StatusRetrievableBufferedWrappedResponse passes Content-Length setting to the wrapped response > _before_ final settlement of this value which leads to situation where Content-Length is set to 0. > > I tried to fix this but whole issue looks to be more troublesome that I previously thought and I > need to rethink whole approach. Basically, I opt to writing our own, full-blown implementation of > HttpServletResponse that will buffer *everything* until we can be 100% sure that everything is > established in final shape. > > This looks like quite a lot of work to implement meaningful implementation of HttpServletResponse > that can copy to another one and will certainly increase complexity of SSF. > > If you have any thoughts on this I'm willing to hear. I regret to say that I probably won't be able to fix this until final release of SSF. I reverted commit blowing up SSF but this does not solves the whole issue, of course. The original bug is still there and it will bite people even in more obscure way because its real consequences can be seen in complicated setups with servlet inheritance only. Nevertheless, it's still better than completely broken SSF. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/