Hello!
We’re working on a web player application which can play back situations from real soccer matches. So far it’s been all working nicely except for some different behaviour in different browser (what a shocker! ;-)).
The main issue is with Explorer!
We’re downloading player movement data, images and other variable data via the WWW class into the application. While the application is running we also have a little routine which checks if any new situation data has been added and notify the user it can be downloaded.
This routine works fine in all browsers except for Explorer.
After the first time you start explorer and try refresh the page, it seems as if it can’t download anything via the WWW class
We’ve tested the “big” browsers on Mac and Windows and Explorer is the only one which doesn’t seem to work properly.
Anyone had any similar issues? I thought I’d give a link to our little beta version of the application. Also, any feedback would be greatly appreciated!
Here’s a working (hopefully) link to a beta version of the web application: http://rbk.zxy.no
I’m not aware of any general issues with the WWW class in Internet Explorer. Do you get any errors the first time you try to pull data? Does this only occur after you’ve refreshed the page (meaning, a fresh page load and all works well)?
why do you refresh the page? I mean it at worst forces a full redownload of the webplayer.
You could simply notify unity of the change through usage of javascript and have unity gather the data then instead of forcefully reloading the whole plugin.
Have not seen such Internet Explorer only related problems on that end yet thought. If then it was normally FF3 on Windows that bugged
I’m working on this as well, so allow me to go a bit more into detail about what we’re doing and what I have found out so far about what makes things go wrong.
We start up a coroutine with a loop that has the single purpose of polling a webpage every X duration to get a small index file. Right now this is done every second.
If the index file has been updated since last time we downloaded it we will do 2 more www downloads based on url information in the index file.
The index file is a html file with the following meta tags to force the browsers to never cache the file:
IE still returns a cached version of the index file through the use of the WWW class even with these tags.
Edit: Actually it randomly returns a cached or a fresh version of the index file. Mostly the cached version.
The issue with not being able to use refresh on the webpage has been resolved, so now it’s only the part about caching in IE that remains.
That’s odd. FWIW, when in the browser we rely on the browser for network operations like this so the Unity Web Player isn’t handling the decision to get a cached version or pull a fresh copy and so this might be due to IE and unavoidable. Do you get the same results if you load that page directly in IE and hit refresh as opposed to loading the page inside your Unity content via the WWW class? If so then I think we can peg this as an IE issue outside of Unity altogether, if not then things get confusing…
Afraid that’s a no. The page refreshes itself perfectly just as expected when opened up in IE for me.
Yeah, confusing certainly is the word I’d use too.
To add to the confusion I’m not even certain if IE caches it or not anymore.
If IE was caching the index file I would expect that a manual refresh of the file in a different tab while running the web app would update the cached version so that the web app would find the new updated version. However the web app still doesn’t find the new version of it more than 90% of the time. Yeah, it’s not even consistently going wrong :?
On top of this if I manually refresh the web app tab after I have updated and refreshed the index file in the other tab, the web app STILL finds only the old version of the index file. This very much suggests to me that there’s some caching going on. Whether it’s the unity webplayer or IE that’s the culprit I don’t know.
If I restart IE I always get the correct version of the index file on starting up the web app.
Had similar issues too. The problem is really here with Microsoft IE’s and MS Proxy servers (from my experience).
The Unity www class is usually fireing off a http POST request which is by RFC a non-cacheable request, other than a GET request which is meant to be to retrieve cacheable data. Now the fun part is that some weird Microsoft software seems to think that caching POST requests is actually a good idea which is of course not. What I did in the end to avoid this is to put into the www form submit also a random value to have the post request look always different. At least to me it solved that issue.
But reading the RFC unveals that you have also to deal with correct cache control headers, otherwise even a POST might get cached! Maybe that is what MS IE is doing here. So make sure your response page has appropriate cache-control headers.
