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!
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
Joined: Jun 28, 2007
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!
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?
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..
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
Joined: Jun 28, 2007
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"
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?
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 ]