5

我正在尝试使用 HttpHandler 将 QuickTime 视频从 ASP.NET Web 应用程序流式传输到 iPhone。从 IIS 5.1 (Windows XP) 托管 Web 应用程序时,视频播放器打开,然后显示错误“服务器配置不正确”。但是,在使用 IIS 7.5 (Windows 7) 时,视频可以正常播放。

生产环境正在运行 IIS 6.0 并且有同样的问题,尝试通过 Mobile Safari 在 iPhone 上播放视频会显示上述错误。

我检查了 Http 标头,它们在两台服务器之间似乎几乎相同(除了一些,例如服务器标头,这显然会有所不同),除了它们以不同的顺序出现,尽管我怀疑这导致问题。

根据Google Groups 上的这个帖子,添加 'Accept-Ranges: bytes' 标头会有所帮助,尽管这对我们没有任何影响。我还添加了 ETag 标头,但没有任何运气。

实际负责发送文件的代码如下所示:

Context.Response.Buffer = true;
Context.Response.ContentType = "video/x-m4v";

Context.Response.AppendHeader("Content-Disposition", "filename=\"Video.m4v\"");
Context.Response.AppendHeader("Content-Length", "23456789");

Context.Response.AppendHeader("Accept-Ranges", "bytes");
Context.Response.AppendHeader("ETag", GetETag(path));

Context.Response.TransmitFile(path);

上面传输文件的代码似乎可以正常运行,并且视频文件在所有桌面浏览器中以及在 Windows 7 上从 IIS 7.5 托管时都可以正确播放。问题仅在使用 Mobile Safari 在 iPhone 上使用 Mobile Safari 播放视频文件时才明显以上代码与托管在 IIS 5.1 或 IIS 6.0 上的 ASP.NET Web 应用程序。

有没有其他人经历过这样的事情并对我可以做些什么来让它工作有任何想法?

4

3 回答 3

3

经过一番搜索,我发现了文章Range-Specific Requests in ASP.NET,它描述了我遇到的确切问题。从这个站点实现RangeRequestHandlerBase类(进行了一些小的修改以适应我们现有的项目结构)似乎已经解决了这个问题,并且视频播放现在可以从 IIS5/6 正确运行。

@Eric - 我赞成你的回答,因为你的评论是朝着正确方向的推动。仅添加“Accept-Ranges”标头是不够的(尽管在 IIS7 中工作),并且需要修改 http 处理程序以处理范围请求并确保发送正确的数据。

于 2009-10-29T01:10:10.597 回答
2

为什么将 Response.Buffer 设置为 true?

除非您还确保服务器支持 HTTP Range 请求,否则您不能简单地添加“Accept-Ranges”标头。如果客户端播放器要求支持 Range 请求而服务器拒绝处理它们,那么请求将被拒绝似乎是合乎逻辑的。

您可以尝试使用 Fiddler 作为反向代理,看看 iPhone 是否发出 Range 请求。 http://www.fiddler2.com/Fiddler/Help/ReverseProxy.asp

于 2009-10-28T14:33:07.870 回答
0

使用 Fiddler 之类的东西来公开来自服务器的确切 HTTP 响应。捏造客户端的 User-Agent 字符串以匹配 iPhone 浏览器(或者只使用 Safari?)并比较 IIS 5.1 和 7.5 的输出。显然,响应流并不相同,或者两者都适用。

您还可以使用 NetMon,它是一个很棒的工具……并且可以让您使用 iPhone 本身进行测试。

抱歉,我没有给你一个具体的答案,但我认为你将不得不用这个弄脏你的手。

于 2009-10-28T06:29:41.913 回答