Hi Leonardo! Thanks for your answer. Sadly jira is currently down, but I will check the posted link later.
But my problem happens at an invokation to the page.xhtml page anyway, and not the users request to page.jsf. To make this more clear. MyFaces itself is not returning a 304, but the JspViewDeclarationLanguage#buildView() gets a 304 from the internal dispatch to get the xhtml from the DefaultServlet! txs and LieGrue, strub --- On Fri, 1/22/10, Leonardo Uribe <[email protected]> wrote: > From: Leonardo Uribe <[email protected]> > Subject: Re: handling of a HTTP 304 not_modified in > JspViewDeclarationLanguage ? > To: "MyFaces Development" <[email protected]> > Date: Friday, January 22, 2010, 12:35 AM > Hi > > Myfaces return HTTP 304 for resources, but does not for jsf > pages. See: > > https://issues.apache.org/jira/browse/MYFACES-2460 > > for details. > > > regards, > > Leonardo Uribe > > 2010/1/20 Mark Struberg <[email protected]> > > 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 > > > > > > > > > >
