我看了下kangle 3.5.11.11服务器响应mp4为304的话，播放器就没法用206状态继续播放，一直卡进度条 etag缓存bug，range http协议，官方开源git仓库
我看了下kangle 3.5.11.11服务器响应mp4为304的话，播放器就没法用206状态继续播放，一直卡进度条 etag缓存bug，range http协议，官方开源git仓库我看了下kangle 3.5.11.11服务器响应mp4为304的话，播放器就没法继续播放，一直卡进度条
播放器锅还是←
好像是播放器不识别304代码
kangle怎么禁止304返回←
用CF CDN没毛病
CF全都是206
改动播放器不是很现实。
论视频返回304状态导致这破B播放器不支持。。
也不知道是不是kangle的问题
补充
自己搭建一个demo，304一点问题都没，播放器的锅←
<!DOCTYPE HTML>
<html>
<body>
<video controls="controls" autoplay="autoplay">
<source src="139.mp4" type="video/mp4" />
你的浏览器不支持HTML5。
</video>
</body>
</html>
确定3.5.11.11是语法BUG问题，如果etag没有变化就回应304，这就是bug
我看了下http协议 if-range是不应该回应304的，如果kangle回了304就是bug
官方已经确认，注释的是原来的代码， 原来的逻辑是如果etag有变化，就清掉range头，响应200，这是正确的。
后来改成了，如果etag没有变化就回应304
这不就是bug了吗？2333，中间优化弄错了。
If-Range的就是etag的内容
10月8号版本导致的问题，等待更新
HTTP协议如下：
The If-Range HTTP request header makes a range request conditional: if the condition is fulfilled, the range request will be issued and the server sends back a 206 Partial Content answer with the appropriate body. If the condition is not fulfilled, the full resource is sent back, with a 200 OK status.
This header can be used either with a Last-Modified validator, or with an ETag, but not with both.
The most common use case is to resume a download, to guarantee that the stored resource has not been modified since the last fragment has been received.
参考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range
在单个请求中，Range头信息能够询问多个范围，这种特性称为"多部分范围（multipart ranges）"。请不要和分段下载（segmented downloading）混淆，几乎任何的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接（每个连接请求文档的不同范围）提高了下载速度。
多部分范围的想法并没有开启多个连接，但是他能够使客户端软件能够在单个请求/响应周期中请求某个文档的最前面的十个和最后面的十个字节。
3.5.11.12已经勉强算修正此问题，视频已经正常播放，虽然还是会出304，但是不影响播放了
影响3.5.11.5-3.5.11.11版本
应该是3.5.11.5，可能更前面两个版本
路过绑定不懂
页:
[1]