cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: svn commit: r562199 - in /cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl: pom.xml src/changes/changes.xml src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/
Date Sun, 05 Aug 2007 10:58:25 GMT
Vadim Gritsenko pisze:
> Grzegorz Kossakowski wrote:
>> pisze:
>>> URL:
>>> Log:
>>> Fix regression introduced in r530406, r532869.
>>> Update changes document: RC1 is long released.
>> At this point I'm not sure how, but your commit breakes servletService 
>> components (generator, transformer and serializer) usage.
> The problem is - was - two fold. First, BlockCallHttpServletResponse did 
> not had a default status code. So when block call is complete and chosen 
> servlet did not set any status code - which it can do - 
> BlockCallHttpServletResponse was returning 0 instead of 200. Revision 
> r562802 fixes this.

I think that Cocoon should *always* set status code and not assume that default one is 200.
However, I can understand that it would be 
harder to fix.

> Second problem is in ServletSource - it was tripping over 0 status code 
> returned by BlockCallHttpServletResponse. It assumes that if status is 
> not 200, it should be 304 - how naive :)
>   if (servletConnection.getResponseCode() != HttpServletResponse.SC_OK) {
>     //most probably, servlet returned 304 (not modified) and we need to 
> perform second request to get data

Oh, and it was me who invented this "clever" code, yes? :)

> Oh, and there is a third problem - I added a FIXME in revision r562800 - 
> it looses original request body once it decides it was a redirect.

You are of course right! Thanks for spotting this issue. What strikes me is word "redirect".
What do you mean by redirect in this case?

I was going to fix COCOON-2096 so could also have a look at this. However, I'm already busy
so if want to fix them both (they are rather 
related, so it makes sense to fix both at once) just let me know so we do not duplicate the

> Actually I don't think we can allow it to perform POST second time at 
> all. Just imagine it was somebody's credit card to be charged $999 - it 
> won't be good at all [1] :)
> Vadim
> [1] Yes in such cases operation should be idempotent - in perfect world, 
> that is...

It was a design decision to assume that POST in this cases will be idempotent. Moreover, this
second request would be sent only if HTTP HEAD 
returned 304, or at least, it was what the code supposed to do. If you don't want this behaviour
because you think it's unsafe just throw 
whole caching away by choosing noncaching pipeline.
Oh, and I can hardly imagine someone implementing charging somebody's credit card and caching
at the same time... :-)


Grzegorz Kossakowski

View raw message