BTW, should it be re-downloading anything at all if it went through the process within a minute or so and the server's IP/port has not changed? What is it actually downloading when this happens--since it's faster than the initial download-- and why is it happening?
I'm not too sure what the expected behaviour is for this so I'm curious. | |
It will re-download some of the items like /play and anything in /res, but resources shouldn't re-download of they're in the cache. The progress bar will still look like it's downloading, but any resources in the cache should be loaded just about instantly by the browser.
| |
Yeah, it's definitely not instant. You're not getting the same issues we're seeing then? This is what I see when reloading the game in Firefox: https://www.youtube.com/watch?v=YruGiYtttz8
| |
No, I've never run into the issues you're seeing. At least not when I test this myself when running a server; testing with a remote server doesn't really help me because I need to see both ends.
My suspicion at this point is that I ought to be including "public" in the Cache-Control header, and that I should also include a Last-Modified header, and add some code to the server to send back 304 in response to any If-Modified-Since on a cache/xxxxx URL. Maybe the first two will improve Chrome's caching behavior, and the last part is needed to respond to any requests to re-download the file that indicate it's still cached. | |
Haven't noticed any changes in the latest version by the way. It's the same as the video I posted.
| |
What do the headers look like now for re-downloaded resources?
In 1334 I added a Last-Modified header, added "public" to Cache-Control, and also added a change that should ignore any requests that include If-Modified-Since by sending back a 304 Not Modified response. When you see a request on a cache/XXXX file that's coming back as 200 OK and doesn't say "(from cache)" what kinds of headers are there? And if you compare those headers to the next time that resource fully re-downloads, what do they look like the next time? I'm still not sure I can rule out bad cache behavior on your browser's part. If you're doing a lot of other browsing, it's possible the browser is simply forgetting those cache files in order to make room for new ones. If not, then it seems unlikely that Chrome should be letting go of the files so early. | |
Response:
Access-Control-Allow-Origin:* General: Request URL:http://74.91.127.229:5000/cache/475058720 | |
The 200 OK (from cache) means it did in fact get the file from the local cache, which is correct behavior. Do you have any examples of /cache/XXXX requests that show 200 OK but don't say they're from the cache?
| |
Lummox JR wrote:
If you're doing a lot of other browsing, it's possible the browser is simply forgetting those cache files in order to make room for new ones. If not, then it seems unlikely that Chrome should be letting go of the files so early. Clearing my cache also didn't help with the issue. It continued just like in the video. | |
It'd be good to know if anyone other than GreatPirateEra is experiencing this issue, also, if any webclient users are reading this.
EDIT: SS13's webclient servers also force a redownload, so I imagine this is a universal thing. | |
I've been running MLAAS with webclient support for a few months and haven't had to redownload the resources once in that timeframe.
| |
Doohl wrote:
I'm pouring through the headers but I cannot seem to find any that are '200 OK' but not from cache. Then it isn't re-downloading. | |
Nadrew wrote:
I've been running MLAAS with webclient support for a few months and haven't had to redownload the resources once in that timeframe. It's redownloading for me. If I reconnect instantly then the download will be a lot quicker, but going away for a few minutes after closing the window gives me the same download speed as the original try. The hub, if other users want to try: http://www.byond.com/games/skysaw/mylifeasaspy | |
You absolutely can't go by how fast the bar moves. You need to look at Chrome's network logs.
| |
ya, the issue is that it still attempts to download it, webclient side, and chrome handles actually deciding if cache has it, meaning the webclient still attempts the download, that's why the time it takes to "download" can very wildly when resolving from cache.
Not much that can be done about that sadly. | |
Hmmmm. This can probably be marked as resolved then. In retrospect I am noticing that Severed's 'download' times are faster than what they are in the video I took after watching it again and comparing.
| |
I'm not too sure about that. Testing on Firefox is giving the exact same issues and every other HTML5 game I've played in Chrome does not redownload and the initial download speeds also seem to be faster.