Hi folks!
I'm not sure if the following is a desired behaviour, so please comment.
I'm using the latest MyFaces-2.0.0-SNAPSHOT together with facelets-1.1.15b1,
jetty-6.1.22 and RichFaces-3.3.3-Beta1.
When I invoke a page, let's say localhost:8080/page.jsf the first time I call
it all is ok. I get the desired page and all is fine.
But If I invoke the page again (reloading or pressing enter in the url bar of
my browser) the following happens (I'm not sure if this also happens with GET
via viewId parameters, but think it will):
1.) The If-Modified-Since timestamp of the http request is still the same as
before (and this does not get cleared) and
2.) will be passed over to the RequestDispatcher (to the page.xhtml) in
JspViewDeclarationLanguage#buildView().
3.) Jetty is so smart to detect that nothing has changed and returns a HTTP 304
(such a response contains headers only, NO CONTENT!). This causes a problem in
4.) the RichFaces ajax4jsf Filter which tries to reformat html to solid XML and
thus crashes with an Exception because it tries to write to the response (which
is immutable due to the 304).
5.) Somehow MyFaces seems to swallow this error (errorResponse is true) and
renders the view from the old tree?
As said above, I guess we will see this more often in JSF-2 due to the fact
that GET will get more common...
Question: Is MyFaces aware of handling a 304? Is this an expected response?
If yes, then RichFaces folks (Alex Smirnov and Jay Balunas) needs to handle the
304 gracefully in their a4j Filter (might be a good idea anyway)
If not, a possible solution would be to simply clean the If-Modified-Since
header from the response before dispatching (workaround suggested by Greg
Wilkins).
Wdyt? A bug? A feature?
(Btw: tried it with Mojarra-2.0.1 and all works ok)
Hope this post didn't get too confusing ;)
LieGrue,
strub
