客户端关闭连接时，来自Apache流M4V与jplayer铬 [英] Client closes connection when streaming m4v from apache to chrome with jplayer
问题描述
我已经成立了一个有点试验场..我想实现一个HTML5视频在站点上我发展发挥，我想用jplayer，使其回落到一个swf文件，如果不支持HTML5视频。
I've set up a bit of a test site.. I'm trying to implement an HTML5 video to play on a site I'm developing and I want to use jplayer so that it falls back to an swf file if html5 video is not supported.
http://dev.johnhunt.com.au/ 是我迄今。它工作正常，如果我提供的http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v对于视频，但如果我是主持人我自己的服务器时，它根本不会开始播放的。
http://dev.johnhunt.com.au/ is what I have so far. It works fine if I provide http://www.jplayer.org/video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v for the video, however if I host it on my own server it simply never starts playing.
MIME类型是绝对正确的，视频/ M4V。查尔斯代理说：
The mime type is definitely correct, video/m4v. Charles proxy says:
Client closed connection before receiving entire response
逸岸，这里的整个请求：
Infact, here's the entire request:
GET /Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host dev.johnhunt.com.au
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=120066461.1007786402.1349773481.1349773481.1349786970.2; __utmb=120066461.1.10.1349786970; __utmc=120066461; __utmz=120066461.1349773481.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Range bytes=0-
和响应：
Some binary data (maybe 3 or 4kbytes long)
这看起来确定。我假设的'客户'是我的Chrome浏览器..为什么会放弃？我该如何解决这个问题？它的驾驶我疯了，因为我无法找到任何谷歌（
Which looks ok. I assume the 'client' is my chrome browser.. why is it giving up? How can I fix this? It's driving me mad as I can't find anything on google :(
当我用jplayer.org的M4V文件，这是要求：
When I use the m4v file on jplayer.org this is the request:
GET /video/m4v/Big_Buck_Bunny_Trailer_480x270_h264aac.m4v HTTP/1.1
Host www.jplayer.org
Cache-Control no-cache
Accept-Encoding identity;q=1, *;q=0
Pragma no-cache
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept */*
Referer http://dev.johnhunt.com.au/
Accept-Language en-US,en;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie __utma=24821473.325705124.1349773077.1349773077.1349773077.1; __utmc=24821473; __utmz=24821473.1349773077.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Range bytes=0-
响应：
Lots of binary data (very long.. working)
干杯，
约翰。
Cheers, John.
推荐答案
我发现，当Chrome浏览器发送一个范围：字节= 0-的要求，你不应该使用206部分内容的回应回应。为了让Chrome浏览器正确处理数据，您需要发送回200 OK的标题。
I've found that when the Chrome browser sends a "Range: bytes=0-" request, you should NOT respond with a "206 Partial Content" response. To get Chrome to handle the data properly, you need to send back a "200 OK" header.
我不知道这是否是正确的根据规格，但它获得的Chrome的工作并没有出现打破其他浏览器。
I don't know if this is correct according to the specs but it gets Chrome to work and does not appear to break other browsers.
这篇关于客户端关闭连接时，来自Apache流M4V与jplayer铬的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
