Prevent servlet response from being cache

[Angel J Gama]

Hi!
This might be an old-school question, but I've just got stuck with this issue, and I'm not sure what would be the best practice for my scenario :S

Here is the thing:
1) I've a main page where the user can check his records ("/panel.jsp"), but the link to retrieve those records before accessing that page is "/servlet/panel.do?lang=en"
2) So, this servlet retrieves the records from the database and save them into a request attribute. Therefore, I use requestDispatcher("/panel.jsp").forward(req, resp); to goto the main page an populate it with the records in the request attribute.

But whenever I goto the servlet link, I get the same old data, no matter if the user inserted new info (the same old-school cache problem)

- I know that a solution would be to add the timestamp in the servlet link (ex: /servlet/panel.do?lang=en&836135165871). But I use this link in many pages. So, what would happen if, later on, I add this link in more pages and I forgot to add/create this timestamp param? I'll get the same old data. That's why I think this is not the way to do it in this scenario. I think that the timestamp practice is good for ajax stuff, isn't it?

- Another solution for this scenario would be to add <meta... "Cache-Control"> tag in every page I don't want to be cache, but I've read that firefox has some problems with this tag. I'm not sure about safari. Am I wrong?

- Since I'm using a requestDispatcher, I can't use response.setHeader. Is there any other thing I can do in the servlet to prevent from being cache?


What would be the best practice to avoid/prevent the response from being cache?
Thanks a lot!

[arulk pillai]

If I understood your question correctly.

the forward and include methods in RequestDispatcher takes response as a parameter.

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/RequestDispatcher.html
[ August 29, 2008: Message edited by: arulk pillai ]

[Angel J Gama]

If I understood your question correctly.

the forward and include methods in RequestDispatcher takes response as a parameter.

You are right, but I'm forwarding it (or them: request and response) to another resource, so the response has not been commited yet. Even if I set headers in the response, they won't be commited at this time.

[Angel J Gama]

I mean, using requestDispatcher I can't prevent page cache by setting response headers. I tried doing this but it was unsuccessful

Is there any other thing I can do in the servlet to prevent from being cache its response?

What would be the best practice to avoid/prevent the response from being cache for my scenario?
Thanks a lot!

[Bear Bibeault]

Originally posted by Angel J Gama:
Since I'm using a requestDispatcher, I can't use response.setHeader.

Why not? That makes no sense at all. I do this all the time and have never had a problem.

[Angel J Gama]

Since I'm using a requestDispatcher, I can't use response.setHeader.

Ok, I didn't explain myself... In the servlet I can do response.setHeader and then use requestdispatcher to forward request and response, but doing that I can't prevent the response from being cache, isn't it?

My questions are:
- What practice can I use to prevent response from being cache (in my scenario)?
- what practices to prevent response from being cache exists?

[Pedro Erencia]

Has really firefox problems with Cache-Control ?
What is the problem in using response.setHeader in the servlet ?
I'd try with META CACHE-CONTROL tag directly on the JSP and find if firefox really has problems with it..

[Bear Bibeault]

Originally posted by Angel J Gama:
In the servlet I can do response.setHeader and then use requestdispatcher to forward request and response, but doing that I can't prevent the response from being cache, isn't it?

No. Where did you hear that?

[Angel J Gama]

I didn't hear that... I'm living it!!!
Here's my situation:

Servlet "/servlet/panel.do"
- retrieves records from database and stores them into a request attribute.
- set header "control-cache" with value "no-cache".
- use requestDispatcher to forward request and response to page "/panel.jsp"

JSP "/panel.jsp"
- Gets the request attribute and creates a table with this info.
- There's a link to another servlet "/servlet/editUser" to edit user's info.

Servlet "/servlet/editUser"
- Gets the record from the database and store it into a request attribute
- set header "control-cache" with value "no-cache".
- Use requestDispatcher to forward request and response to page "/editUser.jsp"

JSP "/editUser.jsp"
- User updates the info (html form) and submits through an iframe.
- servlet "/servlet/updateUser" updates the info and writes into response some text
- JSP reads this response and use javascript to do location.replace("/servlet/panel.do")

Once again in panel.jsp, the information shown is from cache :S So response.setheader before forwarding with requestDispatcher didn't work.


- Any ideas?
- What practice can I use to prevent response from being cache (in my scenario)?
- what practices to prevent response from being cache exists?

[Bear Bibeault]

Did you read this FAQ?

[Victor Dolirio]

I suggest to create one filter intercepting any query to your resources that add the prevent cache headers in the response.
[ August 30, 2008: Message edited by: Victor Dolirio Ferreira Barbosa ]

[Angel J Gama]

Yes Bear Bibeault,
I've read that... have you read my post? response.setHeader(...) isn't working in my servlet.

[Bear Bibeault]

Originally posted by Angel J Gama:
have you read my post?

The one in which you only do part of what is necessary? Yes, I read that.

[Angel J Gama]

Very "nice" Bear Bibeault.

[Bear Bibeault]

What is not nice about trying to get you to either follow the FAQ that's already been thoughtfully set up to solve your problem, or to urge you to be complete in your posts so that we know what you've actually done so that you can get the help you need?

Your posts seem to be saying that you've only done one part of the steps that the FAQs point out. You either need to follow the FAQ more closely, or be more complete in your posts.

Antagonizing the people who are trying to help you is not a winning strategy for getting problems solved. (That's meant to be helpful too. Take it as you will.)
[ August 30, 2008: Message edited by: Bear Bibeault ]