基本上，我在机架空间上有一个视频，我认为它具有正确的cors标头，这些标头我一直使用并且可以正常工作。
Chromecast首先会发出这样的请求：
curl 'video.m3u8' -H 'User-Agent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.81 Safari/537.36 CrKey/1.42.172094' -H 'Origin: https://myreceiverhost' --compressed --insecure
它将返回：
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Request-Headers: *
Cache-Control: public, max-age=259129
Connection: keep-alive
Content-Length: 942
Content-Type: application/vnd.apple.mpegurl
Date: Sat, 14 Sep 2019 16:11:06 GMT
ETag: b0a3cc7fda814676936fcf133e83fb4a
Expires: Tue, 17 Sep 2019 16:09:55 GMT
Last-Modified: Sat, 14 Sep 2019 16:09:43 GMT
X-Timestamp: 1568477382.09591
X-Trans-Id: txf975724d827845e38ee6f-005d7d10f1iad3
然后它将发出类似的请求，该请求也将起作用：
curl 'video.m3u8' -H 'User-Agent: Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.81 Safari/537.36 CrKey/1.42.172094' -H 'Origin: https://myreceiverhost' --compressed --insecure
此回复：
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Request-Headers: *
Cache-Control: public, max-age=259129
Content-Length: 942
Content-Type: application/vnd.apple.mpegurl
Date: Sat, 14 Sep 2019 16:11:06 GMT
ETag: b0a3cc7fda814676936fcf133e83fb4a
Expires: Tue, 17 Sep 2019 16:09:55 GMT
Last-Modified: Sat, 14 Sep 2019 16:09:43 GMT
X-Timestamp: 1568477382.09591
X-Trans-Id: txf975724d827845e38ee6f-005d7d10f1iad3
但是它将发出此请求：
curl 'https://video.m3u8' -H 'Sec-Fetch-Mode: same-origin' -H 'Referer: myreceiverhost/fullpath' --compressed
那失败了。
为什么这样做？我从未见过这样做。
编辑：我刚刚发现了一些很奇怪的东西。我在同一aws s3存储桶上有两个m3u8视频，一个有这个问题，另一个没有。标头是相同的。