使用 azure 托管 silverlight 媒体
我正在考虑使用 Azure Blob 存储托管 MP4。当 azure 使用 url 返回 blob 时，它是否包含 Accept-range 标头。 silverlight 是否能够使用 Azure 存储上的字节范围请求进行提前搜索？
I'm considering hosting MP4s using Azure Blob storage. When azure returns a blob using a url does it include the accept-range header. Will silverlight be able to seek ahead using byte range requests on the Azure storage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，范围请求适用于 blob 存储。我已经看到这个场景完成了（使用 wmv 文件），并且事情似乎工作正常。
Yes, range requests work against blob storage. I've seen this scenario done (with wmv files), and things seem to work fine.
您可以使用 Microsoft 的 Silverlight 流托管，而不是使用 Azure 存储。
它免费为您提供 10 GB，请参阅：
http://silverlight.live.com/
Instead of using Azure stroage you could use Microsofts Silverlight Streaming hosting.
It gives you 10 GB for free, see:
http://silverlight.live.com/
注意（当前）Azure Blob 存储中的跨站点脚本问题 - 您可以从本机 Silverlight 媒体控件调用任何媒体文件，但我发现使用（我认为）HttpRequest 对象存在问题 - 开发人员希望有一个查看媒体文件以了解它有多大（他们正在执行一些涉及缓存文件的操作），并且仅向 blob 存储发出该请求（例如，与托管工作角色 SL 不同的域）会导致跨站点脚本错误。
可恶的
Beware of cross-site scripting problems in (current) Azure Blob storage - you can call any media file from the native Silverlight media control, but I've seen a problem using (I think) the HttpRequest object - the developer wanted to have a look at the media file in order to see how big it was (they were doing something involving caching the file), and just making that request to the blob store (eg a different domain from the worker-role SL was hosted in) caused a cross-site scripting error.
Nasty
我认为我们没有得到第一个问题的答案：“当 azure 使用 url 返回 blob 时，它是否包含接受范围标头？”
我想答案是否定的。我的问题是为什么不可以，有没有办法添加它？似乎某些应用程序（例如 Adobe Reader）不会使用范围，除非原始 GET 返回此标头。
I don't think we got an answer for the first question: "When azure returns a blob using a url does it include the accept-range header?"
I think the answer is no. My question is why not and is there a way to add it? It seems that some apps -- Adobe Reader for example -- won't use ranges unless the original GET returns this header.