Don't refresh page while configuring Vera in IE

Community Playground General Discussions
1

As I touched on in another thread, there seems to be a caching issue where your settings will get into an unexpected state if you refresh the page in Internet Explorer (7). With my current Firefox settings I don’t see the issue, but before anyone gets on an IE bashing roll, IE is doing the correct thing since the HTTP headers don’t specify cache handling or expire values for the JSON call.

What happens is that Vera loads the settings as JSON on initial load and modifies a local copy of the data. Saving the settings does save the settings to the device, but when you refresh the page, the browser returns the originally loaded dataset from the browser cache, thus wiping ot your changes. Saving again puts the old data back in Vera.

Workaround: Load up the configure pages once, but don’t refresh page. If you want to refresh and verify everything got set, close/reopen the browser as this seems to trigger an update.

2

We reproduced the issue and fixed it today. It actually is a bug in IE I was told by our web guy because the whole site had the meta-data “nocache”, and IE was caching it anyway. Regardless, it’s fixed in the firmware we’re releasing today by adding a timestamp to each json request so IE7 won’t cache it.

3

That’s interesting. I was looking at the actual headers coming back for the request and it certainly didn’t have any cache headers applied to it. Mind sharing what technique you were using that didn’t work?

EDIT: If you’re referring to the in the request to “/cmh” then that won’t work in IE (and only applies that to that page anyway and won’t help if there is a real proxy downstream, especially important for remote scenarios).

What I was referring to was the actual call to fetch the JSON data, for example “/cgi-bin/cmh/get_json.sh?file=user_data.json”. This response only has the following headers: “Content-type: text/plain”.

Instead of adding timestamps to the call, you should be able to set the headers on that request similar to what they’re on “/cgi-bin/cmh/get_version.sh”:

Content-type: text/plain
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: 0

Though you’ll want to verify the full list of headers for the current list of browsers you support.

4

It’s possible our main web dev (an ardent Firefox supporter) was too quick to call it a bug. I created a mantis to have him investigate further and be sure the html headers are correct. In any event, I was told the timestamp on the URL also forces IE7 to stop caching the data. http://bugs.micasaverde.com/view.php?id=215

5

I know from my web developing that there are definate issues with IE not following the rules all the time.

6

There is a bug with the meta tag (something similar to the page having to buffer 64k before it takes effect unless you stick another HEAD section at the end of the page), but not the headers (in this case).

Browser wars aside, if the goal is to hit the consumer market, testing on IE 6 & 7 will be crucial (I feel the pain everyday, too).

7

I usually have to test with IE 6&7; Firefox 2&3; Safari and finally Opera. And now with Google releasing their browser, I’ll be adding that to the mix too! It’s definately getting harder to test. (As we speak, I’m checking in on my blackberry which could be used too!)