tags:

views:

126

answers:

3

I have a Java/Wicket page that generates a JNLP file that launches my company's software. This class will optionally take some url parameters and embed them as arguments in the JNLP. When the user launches this JNLP file the client application will perform some function based on those parameters. If the client software is already running on the machine, hitting the JNLP page will instead try to feed these parameters via a remote call to the running client instead of launching a new page.

This part is where I'm having issues. On IE, Firefox and Chrome I could open a new client, but trying to hit the same URL again would instead return a JNLP file. I found that clearing the browser cache fixes this issue on all browsers. Also, I cannot seem to hit breakpoints in the JNLP class, which enforces my hunch that this is more of an issue with the request than something strange with Wicket.

I put the following code in my page class, which extends org.apache.wicket.markup.html.WebPage:

@Override
protected void setHeaders(WebResponse response) {
    getPageMap().remove(this);
    HttpServletResponse httpServletResponse = response.getHttpServletResponse();
    if (httpServletResponse != null) {
        httpServletResponse.setDateHeader("Expires", 0);
        httpServletResponse.addHeader("Cache-Control", "no-cache,no-store,private,must-revalidate,max-stale=0,post-check=0,pre-check=0");
        httpServletResponse.addHeader("Keep-Alive", "timeout=3, max=993");
    }
}

This doesn't seem to work, as Firefox 3.6 still seems to cache the result. IE 7 will work but only after trying the link I create a few times. I don't know a lot about web development and Wicket and this is new to me so it's possible I'm missing something simple.

TL;DR: How do I get a Wicket page to not cache on the client browser?

+1  A: 

Please check the following page: http://palisade.plynt.com/issues/2008Jul/cache-control-attributes/

Firefox should honor the "Cache-Control" header.

João Pinto
While this doesn't directly solve my problem, this link is really great and explains what all these directives do. I'm not really a web guy so a lot of this stuff is a mystery to me.
sfaria
A: 

I don't know Wicket very well but have you tried using WebResponse.setLastModifiedTime(Time time)? I know FF sends an If-Modified-Since header to which your server would reply with 304 Not Modified or the normal response.

It would seem natural to me that your server would check the lastModifiedTime on WebResponse to decide.

If that doesn't help I would suggest you get Firebug for Firefox and take a look at the requests and responses.

zockman
+1  A: 

A hack used in some of the Wicket internals (see for example the source for org.apache.wicket.markup.html.image.NonCachingImage) is to add random noise to the url.

Basically, if you're generating the urls that the browser calls, you can add a parameter ignored by the web application that varies randomly and fools the browser into ignoring its cache.

Don Roby
This seems to be the only easy way, as Joao Pinto's solution doesn't seem to work with any browser, with the pages being served by Jetty 6.
sfaria