myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: handling of a HTTP 304 not_modified in JspViewDeclarationLanguage ?
Date Fri, 22 Jan 2010 09:47:27 GMT
..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 <struberg@yahoo.de>

> 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 <lu4242@gmail.com> wrote:
>
> > From: Leonardo Uribe <lu4242@gmail.com>
> > Subject: Re: handling of a HTTP 304 not_modified in
> JspViewDeclarationLanguage  ?
> > To: "MyFaces Development" <dev@myfaces.apache.org>
> > 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 <struberg@yahoo.de>
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>

Mime
View raw message