Link Details

A little disappointed... it's a filter that returns 304s. GlassFish and TomEE seem to do this already automagically.

Hi Jonathan.

Sorry if my blog wasn't helpful for you. But I'd test that assumption if I were you. Try using Firebug and seeing what gets returned.

Returning 304s isn't something you can do automagically, except for non-dynamic web sites. You really need the application to decide whether something is 'out of date' or not, particuarly if half your page is being pulled from some database.

Richard.

Hey Rich, sorry I came off like an asshat. Your blog is interesting, however, so don't make that assumption.
>
What I meant to say is that the JSF2.0 resource handler combined with GF/TomEE does a fairly good job of pushing 304s on static resources already. Most other applications these days are ajax driven and do partial form submits, so the overhead of processing is extremely low. If you have a legacy app that is using the get/post cycle I can definitely see how this would be useful.>
>
The title lead me to believe there was something magic "go fast" switch in the JVM I didn't know about, that's all I was trying to say.

Yeah, apologies for the title being hyperbolic!

I agree GF/TomEE do a fairly good job of pushing 304s on static resources already. But this blog is explicitly about doing 304s on *non static* resources (i.e the Filter is mapped to *.jsf, not to *.css or *.js). AJAX aside, the JSF page can still be a significant chunk both to send over the network and to construct on the server (especially if it involves database lookups, EL evaluations and the like). I only wrote the blog because I was surprised how nicely this worked out in a client's application, under real world conditions. So may be worth a try.