Really quick answer because I need to run to a meeting:
Safari - I assume you are on Mac then.
Safari open the activity monitor and you can see the requests. Validate that
the urls for the image are the same.
Download either Charles or another monitor type utility - if you have FireFox
use FireBug extension. You can then see the actual requests and the detailed
headers. Then you can look for things like no-cache headers.
Don't bother with IE unless your on windows.
There are some extensions for FireFox I believe that will let you view the
cache as well. IE's cache on *windows* is just easy to see the files and the
urls they came from so if you were on windows its a great low budget easy thing
to do.
Sincerely
Mark R. Jonkman
----- Original Message -----
From: "Victor Subervi" <victorsube...@gmail.com>
To: "Flash Coders List" <flashcoders@chattyfig.figleaf.com>
Sent: Wednesday, March 10, 2010 9:08:55 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Flashcoders] Apparently Doesn't Check Cache
On Wed, Mar 10, 2010 at 9:46 AM, <mark.jonk...@comcast.net> wrote:
> Every request for a file will go back to the server at some level. For
> example, despite the fact that have a file "preloaded' into cache when
> another request is made for the file it will look at the cache then send a
> request to the server to see if the file has changed or whether the file in
> cache is valid to use. If the server returns "use file from cache" then it
> will use the cached file otherwise it will load the "revised" version from
> the server.
>
> First questions would then be what is the header returned as part of the
> original file request. Is it no-cache or does it set a very short expiry?
I have not explicitly set any such header parameters. Here is the code for
index.html:
<html><head>
<SCRIPT language="JavaScript">
<!--
window.location="preload.py?width=" + screen.width;
//-->
</SCRIPT>
</head></html>
and here is preload.py:
#!/usr/bin/python
import cgitb; cgitb.enable()
import cgi
import sys,os
sys.path.append(os.getcwd())
form = cgi.FieldStorage()
width = form.getfirst('width','800')
lines = '''#!/usr/bin/python
def width():
return "%s"
if __name__ == '__main__':
width
''' % width
f = 'width.py'
try:
os.remove(f)
except OSError:
pass
f = open(f, 'w')
f.writelines(lines)
f.close()
os.chmod('width.py', 0755)
print "Content-Type: text/html"
print
print '''
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd";>
<head xmlns="http://www.w3.org/1999/xhtml";>
<meta http-equiv="REFRESH" content="0;url=preloader.swf" />
</head>
</html>
'''
I supplied earlier the code that generates that swf.
Are the url's exactly identical or is there any kind of query string
> associated with the url of one request but not the other?
See above.
> This might be walking on thin ice here, but can you see the file in the
> browser's cache?
I can't figure out where Safari's cache is :( I just tried googling without
success. Lots asking the same question...
> Back in the day, when I was doing Director development, there was a period
> of time that elapsed from when "Shockwave" loaded the file and the time that
> it went into the browser's cache. The file was always available within the
> Shockwave environment but it was immediately visible in the browser's cache.
> Don't know if a similar situation arises with Flash where the content is
> loaded but hasn't yet been written into the browser's cache.
>
> I'd honestly start out by using something like Internet Explorer where you
> can easily browse the cached files -> blow away the cache and then load your
> swf preloader app. See if the files are in cache. If they are cool, note the
> URL associated with them. Then I'd go back and clear the cache again and
> re-run the app with the new window code in place. I'd run it through to
> completion and see if there are two copies of said image in cache one from
> the swf preloader and the other from the new window. If so it would imply
> that they must be seeing slightly different urls.
Well in that case, before I d/l Exploiter, they are indeed seeing different
urls, as you can see from the above.
> If not then I'd be looking for no cache headers. Concurrent to this I'd be
> using something like Fiddler (IE), Charles or Tamper Data or similar app
> that will allow you to see the requests and the responses and be able to
> examine the headers and check for no-cache or very short expiry on the
> headers.
>
Please advise me on what I've answered above if you believe that's where the
problem lies. Otherwise, I'll start experimenting with what you've
recommended here below.
TIA,
V
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
