0

How can I make the browser of a client load the new version of the html page with a new java applet?

We updated a system in the field, but when the client connected to the web server, the old java applet was still shown (from the cache).

How can I force (preferably from the server side) the client to load the new version instead of the one from it's cache?

Old system (before upgrade) :

  • old linux version (more than 10 years old)
  • old apache webserver (more than 10 years old)
  • old java applet (separate class files) (about 2 years old)
  • old index.html in webserver root dir (about 2 years old)

New system (after upgrade) :

  • same IP address and port as the old system
  • windows xp embedded
  • apache/2.2.21 (win32) webserver
  • new java applet in jar file (all different class names from the old version)
  • new index.html in webserver root dir

The user is using Chrome on a Windows XP machine

When the user loaded the page in Firefox, the new java applet was shown and working flawlessly. (He never loaded the old java applet in firefox)

[EDIT]

adding the lines from looper to my httpd.conf did not lead to any errors, but i am not sure if it works either ...

i don't seem to be able to reproduce the caching problem of my client : when i change something the in the applet and load it again from another computer, then nothing changes, but when i reload a few minutes later, it does show the new version .. without or without those extra lines with CacheDisable

when i search my httpd.conf for "cache" then all i find is :

#LoadModule cache_module modules/mod_cache.so
#LoadModule disk_cache_module modules/mod_disk_cache.so
#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule mem_cache_module modules/mod_mem_cache.so

so it seems no caching is enabled ?

when i add the line with CacheDisable by itself (without IfModule), then Apache doesn't want to start, so it probably corrupts httpd.conf ?

[EDIT2]

as the server OS, web server, java class names, and all filenames except index.html are different from the old version, it must be the cached index.html which is the cause of the problem. I added the meta tags from FrancescoMM's answer to my index.html, and hope this will prevent the problem for future releases

Hrqls
  • 2,944
  • 4
  • 34
  • 54
  • @zch : the old system doesn't use a jar file (all separate class files), the new system does use a jar file, so you could say the jar file has a different name (and the names of the classes in the jar file are all different from the old classes as well) – Hrqls Nov 22 '12 at 14:26

3 Answers3

1

Unless you put functionality that allows the applet to invalidate itself based on a server instruction, you'll have to do reset from the client side. Clearing the cache on the browser should do, from the information provided. Every browser has a way of clearing its cache. I don't believe there's a shorter way than that.

Every system turns into a legacy system the moment it's first deployed. It's always a good idea to plan for upgrade. At the very least, any applet that does server communication should report its version number to the server, enabling the server to reject service, start upgrade, notify the user, or whatever else is appropriate.

eh9
  • 7,340
  • 20
  • 43
  • that's what we did this time: inform the user, and guide him through the menus to clear the cache .... we might not always know who is using it though, so we can't always inform everyone, and i think it's not very user friendly to make them clear their cache whenever we have an update – Hrqls Nov 27 '12 at 13:47
  • 1
    Not it's not particularly friendly, which is why people have developed ways of doing auto-update. I'm not sure the right solution is for an applet, but it almost certainly involves some JavaScript and an AJAX call to check for the current version. Once you're inside the applet sandbox, you won't be able to do much. – eh9 Nov 27 '12 at 14:12
  • 1
    ... that is, assuming renaming the JAR on the server side doesn't work for you in the future. – eh9 Nov 27 '12 at 14:21
  • i forgot to mention : i like your comment about reporting the version number, i don't have access to the server code though .... my applet communicates with some servers via a tcp port (get data from traffic controllers, write data/instructions to them) ..... the processes in the traffic controllers with which my applet communicates are not mine .. the old applet which was running at the same IP address isn't mine either, i install remove the old computer (hardware) install a new one with a new OS and my html and jar files .. everything changes except the IP address and filename of index.html – Hrqls Nov 27 '12 at 14:24
  • the old applet should not have worked either : all the classes were gone from the server (even a totally new OS and webserver version) .... the inter-communication also changed (old applet via shared mem, new applet via tcp port) ... – Hrqls Nov 27 '12 at 14:28
  • It sounds like you have a new SO question to ask, one about how to accomplish a certain goal with only a restricted ability to configure the server side. – eh9 Nov 27 '12 at 15:10
  • sorry, i am quite new to this site, what is an SO question ? who should have a (restricted) ability to configure the server side ? – Hrqls Nov 27 '12 at 15:35
  • SO = Stack Overflow. _You_ seem to be the one with limited ability to change the servers. – eh9 Nov 27 '12 at 18:02
  • ah of course SO = stack overflow ... lol .. proving to be blond :) ... i have full control over the web server (apache), and over the java applet and html pages, just no control over the data processes in the traffic controllers, and (almost) no control over the users OS and browser settings ... will post a new question with a javascript tag – Hrqls Nov 28 '12 at 06:19
  • +1 for the effort and help, thanks! :) ... will think about the question to ask with a javascript and/or ajax tag .. that probably is the path to go indeed – Hrqls Nov 29 '12 at 07:10
1

If the java classes are different, then the index file is the one that is in cache. It could also be the client proxy cache, so acting on the server has no result.

The fastest solution is to send a new url to the client:

http://www.site.com/index.html?random_param=1234
http://www.site.com/?random=1234
http://www.site.com/?1234
http://www.site.com/?new

or even just

http://www.site.com/?

should be enough.

EDIT

Also, have you tried adding all the pragma no cache and expiration date meta tags to the HTML page? That should tell the client proxy to reload the page anyway.

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">

Note that EXPIRES is set to an old date on purpose. This may not solve your problem this time, as if the new index is not loaded, nobody (server, proxy, client) will see the new tags, but will make sure the next time the page is loaded every time.

FrancescoMM
  • 2,845
  • 1
  • 18
  • 29
  • would that place the new index file in the cache of the user ? that would be a nice way to update the cache (without having to lead the user through its browser settings) – Hrqls Nov 28 '12 at 14:02
  • I used to do this with Flash content that is very hard on cache: go to http://www.site.com/?new hit CTRL+F5 (on Windows PC) then go to http://www.site.com/? hit CTRL+F5 then go to http://www.site.com/ hit CTRL+F5. This usually fixed it forever. – FrancescoMM Nov 28 '12 at 14:24
  • 1
    thanks!! those meta tags should do the job i think (from what i see in the docs) ... can't test it right now though ... but i think you hit the cause of the problem : the old index.html is read from the cache, and that index.html still refers to the old class files .. so when index.html is no longer read from the cache, then my new applet jar file will be loaded .. or at least it should! :) – Hrqls Nov 29 '12 at 07:14
0

Just force no-cache in Apache in the httpd.conf.

From the apache-docs:

<IfModule mod_cache.c>
    CacheDisable /local_files
</IfModule>

Instead of disabling cache for all local files, you can specify the complete path to the applet-file.

looper
  • 1,929
  • 23
  • 42