Vadim Gritsenko pisze:
Not entirely true. It is perfectly fine for servlet application to not
set any status code at all. Container will assume 200 and move one. And
final HTTP response always will have some status set.
But since Cocoon here plays a role of container, it should perform
container's functions - namely, BlockCallHttpServletResponse should now
have a default code of 200, *not* 0 - to handle scenario above.
and not assume that default one is 200. However, I can understand that
it would be harder to fix.
Nothing's to fix anymore, see explanation above :)
Ok, thanks for clarification.
Oh, and it was me who invented this "clever" code, yes? :)
Sorry, I have no idea who wrote it.
It was rhetoric question ;)
See r531498[1]
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?
Sorry, above "redirect" should read "not modified". BTW, are you setting
If-Modified-Since request header anywhere? ...... Yes I see that you do.
Ok.
Honestly, I got no idea what this code does :) So I'm not sure what I
should be fixing :) Having said that... *If* I get another chunk of
time... I might look into it...
I thought that the code was pretty well commented and annotated.
It's worth to take a look at COCOON-2046[2] because it contains further links
that would allow you to understand goals behind this code.
If you have any suggestions about code documentation (something is not
commented clearly enough) feel free to share them with me here.
Oh, and I can hardly imagine someone implementing charging somebody's
credit card and caching at the same time... :-)
Caching would be handy if your clientèle is a bunch of lemmings ;-)
;-)
[1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/24126
[2] https://issues.apache.org/jira/browse/COCOON-2046
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
