2009-10-28 59 views
5

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

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

我检查HTTP标头,他们似乎是几乎在两个服务器之间是相同的(除了少数,如服务器头,这显然是不同的),除非他们出现在不同的顺序尽管我怀疑这是造成这个问题的原因。

根据Google Groups上的this thread,添加'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); 

高于该传输文件中的代码似乎正常和视频文件中的所有桌面浏览器可以正常播放,并从IIS托管时7.5。在使用移动Safari在iPhone上播放视频文件时,只有在IIS 5.1或IIS 6.0上托管ASP.NET Web应用程序的情况下使用上述代码才会显示问题。

有没有其他人经历过这样的事情,并得到我能做些什么来得到这个工作的任何想法?

+0

Accept-Ranges提示帮助我解决了与ASP.NET MVC类似的问题。 – kim3er 2010-02-18 16:08:28

回答

2

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

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

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

0

使用类似Fiddler的方式公开来自服务器的确切HTTP响应。默认客户端的用户代理字符串以匹配iPhone浏览器(或仅使用Safari?)并比较IIS 5.1和7.5的输出。很明显,响应流不完全相同,或者两者都有效。

你也可以使用NetMon,这是一个伟大的工具...并且可以让你测试iPhone本身。

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

+0

感谢您的提示。该视频在Windows上的Safari中实际播放效果良好,在使用iPhone用户代理字符串时也在Firefox中播放,所以我不认为这是与此相关的。这个问题看起来更像是IIS5/6如何传输文件,而不是IIS7,它不允许iPhone播放它。以前没有使用网络监控工具,但会检查NetMon/Wireshark并查看它们是否可以提供帮助。 – Mun 2009-10-28 14:09:52

3

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

@Eric - 我已经upvoted你的答案,因为你的意见是正确的方向微调。只需添加'Accept-Ranges'标头是不够的(尽管在IIS7中工作),并且需要修改http处理程序来处理范围请求并确保正在发送正确的数据。