looking at the behaviour, this may also be the reason for the BadPaddingException mentioned in https://issues.apache.org/jira/browse/MYFACES-2478 and https://issues.apache.org/jira/browse/MYFACES-1838.
This happens always when I'm not fully requesting a new rendering via ctrl-shift-r in firefox. If I blast the If_modified_since, it's gone too. LieGrue, strub --- On Fri, 1/22/10, Mark Struberg <[email protected]> wrote: > From: Mark Struberg <[email protected]> > Subject: Re: handling of a HTTP 304 not_modified in > JspViewDeclarationLanguage ? > To: "MyFaces Development" <[email protected]> > Date: Friday, January 22, 2010, 11:41 AM > It seems so. > > Take any start page (GET!) you like and set a breakpoint to > > > JspViewDeclarationLanguage line #84 > boolean errorResponse = wrappedResponse.getStatus() < > 200 || wrappedResponse.getStatus() > 299; > > Then submit the page multiple times (e.g via pressing > Ctrl-R in firefox) > > The first time errorResponse is false, but true on any > subsequent request. > > In fact a 304 is not an error... > > LieGrue, > strub > > --- On Fri, 1/22/10, Jakob Korherr <[email protected]> > wrote: > > > From: Jakob Korherr <[email protected]> > > Subject: Re: handling of a HTTP 304 not_modified in > JspViewDeclarationLanguage ? > > To: "MyFaces Development" <[email protected]> > > Date: Friday, January 22, 2010, 10:47 AM > > ..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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
