..and the 304 only happens because of the header field? if so, I think we should remove this header to make it work correctly!
Regards, Jakob 2010/1/22 Mark Struberg <[email protected]> > 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 > > > > > > > > > > > > > > > > > > > > > > > >
