views:

105

answers:

2

Hi all,

I'm having trouble with a particular version of Pocket IE running under Windows Mobile 5.0. Unfortunately, I'm not sure of the exact version numbers.

We had a problem whereby this particular 'installation' would return a locally cached version of a page when the wireless network was switched off. Fair enough, no problem. We cleared the cache of the handheld and started sending the following headers:

Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Thu, 30 Jul 2009 16:42:08 GMT

The Last-Modified header is calculated on the fly and set to 'now'.

Even still, the handheld seems to be caching these pages: the page is sent with the headers but then when they disconnect the wireless network and click a link to the page (that was not supposed to be cached) it still returns this cached file.

Is there some other header/s that should be sent, or is this just a problem with Pocket IE? Or is it possibly something entirely different?

Thanks!

+1  A: 

I'm not sure I can answer your question since I have no Pocket IE to test with, but maybe I can offer something that can help.

This is a very good caching reference: http://www.mnot.net/cache_docs/

Also, I'm not sure whether your example is the pasted results of your headers, or the code that you've set up to send the headers, but I believe the collection of headers in most language implementations (and by extension I assume most browser implementations) is treated as a map; therefore, it's possible you've overwritten "no-store, no-cache, must-revalidate" with the second "Cache-Control" header. In other words, only one can get sent, and if last wins, you only sent "post-check=0, pre-check=0".

You could also try adding the max-age=0 header.

In my experience both Firefox and IE have seemed more sensitive to pages served by HTTPS as well. You could try that if you have it as an option.

If you still have no luck, and Pocket IE is behaving clearly differently from Windows IE, then my guess is that the handheld has special rules for caching based on the assumption that it will often be away from internet connectivity.

Edit: After you mentioned CNN.com, and I realized that you do not have the "private" header in Cache-Control. I think this is what is making CNN.com cache the page but not yours. I believe "private" is the most strict setting available in the "Cache-Control header. Try adding that.

For example, here are CNN's headers. (I don't think listing "private" twice has any effect)

Date: Fri, 31 Jul 2009 16:05:42 GMT
Server: Apache
Accept-Ranges: bytes
Cache-Control: max-age=60, private, private
Expires: Fri, 31 Jul 2009 16:06:41 GMT
Content-Type: text/html
Vary: User-Agent,Accept-Encoding
Content-Encoding: gzip
Content-Length: 21221

200 OK

If you don't have the Firefox Web Developer Toolbar, it's a great tool to check Response Headers of any site - in the "Information" dropdown, "View Reponse Headers" is at the bottom.

Renesis
Thanks for the notes. Just wanted to say that I had copied the headers from my PHP code and 'tweaked away' the PHP code. Hence the incorrect headers: I've edited the post and copied in an exact copy of the headers (as far as Firefox is concerned, anyway).Just wanted to let you know that: I'm off to read that link and try the max-age header, too, thanks.
Narcissus
In case Pocket IE is implementing some funny rule, it's possible that because it sees the presence of "Last-Modified" it assumes it CAN cache the page for some amount of time. You could try removing it altogether and eliminating the chance that Apache could return a 304 Not Modified.It seems according to the following link that this is meant to tell browsers to always simply obey the Expires header.http://www.askapache.com/htaccess/apache-speed-last-modified.html
Renesis
More information: have tried the max-age headers, as well as removing the last-modified header. Still no dice. The annoying thing is that when they visit cnn.com (for example) the handheld doesn't cache the pages, so I'm starting run out of ideas :(
Narcissus
Please see my addition to the original answer above.
Renesis
Thanks Renesis: I added that 'private' entry to the cache-control (twice, just in case :)) and still nothing. Basically I've given up and gone the 'cheat' route.
Narcissus
A: 

Although Renesis has been awesome in trying to help me here, I've had to give up.

By 'give up' I mean I've cheated. Instead of trying to resolve this issue on the client side, I went the server side route.

What I ended up doing was writing a function in PHP that will take a URL and essentially make it unique. It does this by adding a random GET parameter based on a call to uniqid(). I then do a couple of other little things to it: make sure I add a '?' or a '&' to the URL based on the existence of other GET parameters and make sure that any '#' anchor items are pushed right to the end and then I return that URL to the browser.

This essentially resolves the issue as each link the browser ever sees is unique: it's never seen that particular URL before and so can't retrieve it from the cache.

Hackish? Yes. Working? So far, so good.

Narcissus