myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: handling of a HTTP 304 not_modified in JspViewDeclarationLanguage ?
Date Fri, 22 Jan 2010 13:43:29 GMT
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 <struberg@yahoo.de> wrote:

> From: Mark Struberg <struberg@yahoo.de>
> Subject: Re: handling of a HTTP 304 not_modified in JspViewDeclarationLanguage  ?
> To: "MyFaces Development" <dev@myfaces.apache.org>
> 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 <jakob.korherr@gmail.com>
> wrote:
> 
> > From: Jakob Korherr <jakob.korherr@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, 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 <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