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
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



Reply via email to