Firefox 中的 Flash 影片使用 URLLoader 间歇性加载 XML
我有一个 Flash 影片,其行为如下:
影片加载 >尝试使用 URLLoader.load() > 加载 XML 文件使用 XML 中的数据将一些图像加载到电影中。
要求是在 10 分钟内获取 XML 文件的更新,因此我向 XML URL 添加了一个查询字符串参数,该参数是最近十分钟的时间戳,例如 example.com/source.xml**?nocache =2011-0-6_11-40**
这一切都按预期在 IE 和 Chrome 中为我工作,并且在 Firefox 中为我本地工作。然而,在我们的 Firefox 生产服务器 (IIS) 上,会发生以下行为(通过观察 Firebug):
首次加载: SWF 加载 > XML 请求和加载 >请求并加载图像
后续页面加载: SWF 加载 >没有对 XML 的请求(Firebug 中没有显示请求)
Firebug 显示第一个成功请求中有关 XML 文件的以下信息:
响应标头
缓存控制 max-age=31536000
内容长度 640
内容类型text/xml
内容位置 http:// /www.example.com/portals/0/flash/slider3/list.xml?nocache=2011-0-6_11-30
最后修改时间 2011 年 1 月 6 日星期四 08:08:12 GMT
接受范围字节
服务器 Microsoft-IIS/6.0
X-由 ASP.NET 提供支持
服务者:9002
日期 2011 年 1 月 6 日星期四 11:38:00 GMT
请求标头 托管 www.example.com
用户代理 Mozilla/5.0(Windows;U;Windows NT 6.1;en-GB;rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
接受text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
接受语言 en-gb,en;q=0.5
接受编码 gzip,deflate
接受字符集 ISO-8859-1,utf-8;q=0.7,*;q=0.7
保持活动 115
连接保持活动
__utma=39412577.29609269.1294313877.1294313877.1294313877.1; __utmb=39412577; __utmc=39412577; __utmz=39412577.1294313877.1.1.utmccn=(直接)|utmcsr=(直接)|utmcmd=(无)
缓存
最后修改时间 2011 年 1 月 6 日星期四 11:38:00 GMT+0000(GMT 标准时间)
最后获取时间:2011 年 1 月 6 日星期四 11:38:00 GMT+0000(GMT 标准时间)
过期日期:2012 年 1 月 6 日星期五 11:38:00 GMT+0000(GMT 标准时间)
数据大小 640
获取计数 2
设备磁盘
密钥: http: //www.example.com/portals/0/flash/slider3/list.xml?nocache=2011-0-6_11-10
数据大小:640字节
获取次数:2
最后修改: 2011-01-06 11:01:25
过期时间: 2012-01-06 11:01:25
我不明白什么会导致 URLLoader 不创建出现在 Firebug 中的请求。如果它从浏览器缓存中检索 XML,为什么电影无法正常工作(加载图像等)?
I have a Flash movie that behaves as follows:
Movie loads > tries to load an XML file using URLLoader.load() > uses the data in the XML to load some images into the movie.
The requirement was for updates to the XML file to be picked up within 10 minutes, so I have added a querystring parameter to the XML URL which is a timestamp to the nearest ten minutes, e.g. example.com/source.xml**?nocache=2011-0-6_11-40**
This all works for me as expected in IE and Chrome, and it works locally for me in Firefox. However, on our production server (IIS) in Firefox, the following behaviour occurs (by observing Firebug):
First load:
SWF loads > XML Requested and loads > images requested and load
Subsequent page loads:
SWF Loads > no request for the XML (no request shown in Firebug)
Firebug shows the following information about the XML file from the first successful request:
Response Headers
Cache-Control max-age=31536000
Content-Length 640
Content-Type text/xml
Content-Location http://www.example.com/portals/0/flash/slider3/list.xml?nocache=2011-0-6_11-30
Last-Modified Thu, 06 Jan 2011 08:08:12 GMT
Accept-Ranges bytes
Server Microsoft-IIS/6.0
X-Powered-By ASP.NET
ServedBy :9002
Date Thu, 06 Jan 2011 11:38:00 GMT
Request Headers
Host www.example.com
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
__utma=39412577.29609269.1294313877.1294313877.1294313877.1; __utmb=39412577; __utmc=39412577; __utmz=39412577.1294313877.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
Cache
Last Modified Thu Jan 06 2011 11:38:00 GMT+0000 (GMT Standard Time)
Last Fetched Thu Jan 06 2011 11:38:00 GMT+0000 (GMT Standard Time)
Expires Fri Jan 06 2012 11:38:00 GMT+0000 (GMT Standard Time)
Data Size 640
Fetch Count 2
Device disk
Key: http://www.example.com/portals/0/flash/slider3/list.xml?nocache=2011-0-6_11-10
Data size: 640 bytes
Fetch count: 2
Last modified: 2011-01-06 11:01:25
Expires: 2012-01-06 11:01:25
I don't understand what would cause URLLoader to not create a request that appears in Firebug. And if it is retrieving the XML from the browser cache, why isn't the movie working (loading the images etc)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们解决了这个问题 - 内容编辑器使用的 XML 文件顶部没有 XML 声明,即
自从我们更正 XML 文件后,该问题没有再次出现。
We resolved this issue - the content editor was using an XML file that did not have an XML declaration at the top, i.e.
The issue has not reappeared since we corrected the XML file.