Re: Cache problem with IE
Hi,
AFAIL, this doesn't work with some IE versions(5 and above I think) the
problem is caused because IE5+ decides whether it wonts to cache the
page if the page is greater than 32k. So, when it decides that the page
has to be cached, the headers have been long ago forgotten :(. The
solution in our case was to add also the "no caching, please" piece of
html at the end of the pages. So our pages end up being something
like...
html
head
meta http-equiv="Expires" content="now" /
meta http-equiv="Cache-Control" content="no-cache,
must-revalidate"/
meta http-equiv="Pragma" content="no-cache" /
...
/head
body
...
/body
head
meta http-equiv="Expires" content="now" /
meta http-equiv="Cache-Control" content="no-cache,
must-revalidate"/
meta http-equiv="Pragma" content="no-cache" /
/head
/html
This trick works for us on all the browsers I have tested so far.
I hope this helps,
Dan
References:
http://support.microsoft.com/support/kb/articles/Q222/0/64.ASP
http://support.microsoft.com/support/kb/articles/Q234/2/47.ASP
Tagunov Anthony wrote:
On Tue, 13 Mar 2001 17:13:14 +0100, Zsolt Koppany wrote:
Hi,
with the code below I can get netscape not to cache a jsp page but it
does not work with Internet-Explorer.
Does anybody know why?
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");\
Hitting the same problem we used at
http://www.mavicanet.com
and it works both on NS and IE!
response.setHeader("Pragma","no-cache");
response.setHeader("Cache-Control","no-cache");
response.setHeader("Expires","Thu, 01 Dec 1994 16:00:00 GMT");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: detecting shutdown
Hi David, AFAIK there's no such a thing in any servlet container that I've worked with, but I might be wrong as my experience with Tomcat is quite limited. However, this wouldn't be a logical option as the same that you say about unloaded!=tomcat stopping can be said of loaded. AFAIK loaded!=Tomcat just started but it just means tomcat just loaded the servlet. Thus, if Tomcat decides to unload/reload your servlet for any reason and then tomcat is stopped you would end up with multiple initialisations and just one finalisation. Ummm, I think that with JSDK 2.3 you might try to do what yoy want with the class ServletContextListener, which is notified when the context is initialised or destroyed. With JSDK 2.2 I'm not sure how could one verify that everything is really shutting down before clearing things up. We solved it by using just ONE servlet which acts as ServletController and who initialises everything when being loaded and cleans everything when unloaded, but I understand this is not a general solution. I'm afraid I can't help you much with JSDK2.2. May be someone out there? ;) regards, Dan David Wall wrote: Is there something like the web.xml's "load on startup" that can be triggered when the Tomcat has been requested to shutdown? I'd like to be able to do "global" cleanup in such a situation. I know that an unloaded servlet will be called, but it's not true that being unloaded means that Tomcat is stopping. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Form based auth. again...
Hi Vladimir, snipped for brevity I'm thinking along the same lines... You could also embed a tiny invisible image in protected area to your front page (named /welcome, for example) and define your login form as /welcome?mode=login, so whenever you're not authorized welcome page is smart to display you a login form... The problem here is that it's difficult to display a meaningful message that a user needs to login whenever (s)he actually tries to get a real protected page since it'll always display /welcome?mode=login. Something like that... On that regards. Whe we developed our own authentication mechanisms, we also took into account this specific problem and what we did was the following: .- The authentication system tries to authorise the user. .- If it fails, it returns a meaningful error code as no_log_in, wrong_password, session_timed_out... .- The system then checks if there's a specific forward page for the error code, somewhere in the configuration file (something like forward.page.wrong_password="/check_pass.html") .- If it exists, it forwards control to the specific page, otherwise it forwards control to the default page which would be the login page. This way, if you want to return a meaningful message you just have to create an html file with the proper message and configure it appropriately. It's not mandatory but in some situations and depending on the "level of knowledge" of your users, this is a very useful feature. Of course, this would imply a more complex authentication system, even though not much, and it would be something outside the spec. Just my 2c, Dan Havent tried it, tell me if it works if you do. And if you got any workaround by the way. I also seem to have read somewhere that you can do what you want using the JDBCRealm. Have you tried anything on that line? As far as I understand JDBCRealm has little to do with it. It's just a mechanism facilitating authentication, you give it [name, password, role] and it tells you if you're good to go using a database instead of tomcat-users.xml. that's it. Christian Rauh [EMAIL PROTECTED] NewTrade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
