Copy link to clipboard
Copied
We have an application that runs code and writes log output to the screen in Flash Player. If a user runs code over and over, generating a large log file, eventually, the file appears to be truncated, and not all the lines are displayed. The file on the server is correct and complete, but it just can't all be displayed. Clearing the Flash Player cache corrects the problem and allows the whole file to be displayed, but that also involves a restart of the browser which is a big pain for the user. Is there any way to work around this? Is there a way to specify a larger cache size? Or clear the cache without the restart?
Thanks,
Ann
Copy link to clipboard
Copied
I'm going to lead with a recommendation that I think will solve it:
In the request that you're making for the logs, just append a GET parameter with a random value to the URL. It's quick and dirty, but it's very effective, particularly on older clients that might have weird caching behaviors (or not correctly support more elegant server-side headers). The trick is just to make sure that the GET parameter is unique for each request, such that nothing in the pipeline can cache it.
example: http://domain.com/showLogs.php?entropy=98712471309135097239
I can see why the scenario you're describing might get you right outcome, but I think it's happening for different reasons. In general, the browser mediates network requests and would generally make the decision about whether to fetch an item from the network or the browser cache. I suspect that exiting the browser is really solving a caching problem within the browser itself. Furthermore, refreshing the page would cause that Flash process to exit, and a new one would be spawned at launch. I assume that you would have mentioned it if refreshing worked, so since it persists across multiple Flash Player invocations, it's more likely that it's a state that persists in the host environment.
I have some questions that would better inform the thesis behind my recommendation, but I don't think they're worth your time to answer unless you're still stuck after trying the entropy thing.
The ideal next step would be to just share a reduced example that we can run under a C++ debugger. If it's really a Flash Player bug, looking at what the player is doing at runtime is far more informative than looking at ActionScript, I suspect that if this *is* our bug, it's probably something weird that only happens under memory pressure (which is why it shows up after lots of appends to really large textfield bodies).
That said, here are the things I'd really like to know:
Copy link to clipboard
Copied
To answer a couple of your questions... it is a Flex application, and the customer has reported seeing the problem with Flash 23 and 25 on IE and Flash 24 on Chrome, so it is not specific to a single browser.
Copy link to clipboard
Copied
That's useful, thanks. I still think that a cache busting technique is your best bet.
If you cannot recompile the application with that change, or it's super painful, you might experiment with server-side caching headers like Cache-Control: no-store for the affected responses. Again, I'm not sure how consistent your outcomes will be, and they'll probably vary depending on the browser and version. (See: Cache-Control - HTTP | MDN )
Copy link to clipboard
Copied
Looking at the Network tab at the response headers, they all have Cache-Control set to no-cache. Perhaps I'm wrong in thinking this is a cache problem. With regard to recompiling, I doubt that's an option.
Copy link to clipboard
Copied
Try Cache-Control: no-store. Cache-Control: no-cache still allows items to be fetched from the cache.
If recompiling is a non-starter, your workaround is probably limited to using a browser that doesn't exhibit the problem.
Copy link to clipboard
Copied
Actually, if you're really stuck (you don't have the application source, can't redeploy, etc.) maybe you could do something tricky with the webserver, like issue redirect requests for that log file to append a random GET parameter. That's super ugly, but you could probably make it work with mod_redirect or an equivalent. Definitely sub-optimal, but it might be the lesser of the evils.