Since OTA Provisioning requests occur over HTTP on the Sprint network. The Sprint Gateway's caching poses a problem when you try to frequently update your content during testing. When I updated a piece of code in my MIDlet and placed the new JAR into the Web server, I noticed that a new request from the handset for the JAD did not return the updated JAR to the handset. In fact, checking the server logs, I noticed that no new requests had been made for the files.
The solutions I propose are adding extra HTTP headers that tell the Gateway that the file should not be cached and creating a workaround that simply adds a random query string to the URL to trick it into thinking it needs to make a new request for entirely different content.
Using HTTP Headers
There are two ways to specify that certain groups of files or a particular file should not be cached by the gateway:
- Specify it in the HTTP header via something like PHP or Perl when outputting a file.
- Configure the Web server to mark certain MIME types as non-cacheable.
To mark a file as non-cacheable in PHP, add the following line of code somewhere in the file prior to outputting anything else:
For testing purposes on the development server, I've configured the server to specify that files with the extensions .jar and .jad should never be cached. This allows me to mark a group of files as non-cacheable and frees me from having to use the first method described above, which taints my code. Again, I am using the Apache httpd server. Configuring your server probably will be different, so consult the documentation.
In your httpd.conf file, uncomment the lines of code that look like this:
LoadModule expires_module modules/mod_expires.so
This will activate the expiration module. If you haven't added the appropriate MIME types for .jar and .jad file extensions as I specified previously, then do so now. Next, add the following three lines at the end of the file to mark .jar and .jad as non-cacheable:
ExpiresByType text/vnd.sun.j2me.app-descriptor "access plus 1 second"
ExpiresByType application/java-archive "access plus 1 second"
This tells the proxy or browser that files of type .jar and .jad expire one second after they've been accessed. Don't use this for deployment purposes, however; there are good reasons for the gateway caching.
Adding a Random Query String
If you have absolutely no access to either your server's configuration file or a processing language like PHP or Perl, you can trick the gateway into thinking that a new request you make is for a completely different file. Just append a random query string to the JAR or JAD's URL.
Using my fictitious URL for the SimpleMidlet, the change will look like this:
HTTP://webserver/SimpleMidlet.jad?r=[some random number]
This ensures that the gateway will request the file anew from your server.
This works only if you need to download a new version of the JAD. To download a new version of the JAR, you'll have to modify the MIDlet-Jar-URL using the same scheme as you did for the JAD. The new entry will look something like this:
MIDlet-Jar-URL: HTTP://webserver/SimpleMidlet.jar?r=[some random number]
A word of caution: you might run into trouble with tools like KToolBar if you add too many pre-processing directives to the JAD. Keep them to a minimum.