Why won't Safari play file without extension i

问题:

I have file named 52bbb58c without file extension and it is mp4 video.

When I try to add it as &<source> to <video> with attribute type (video/mp4), it doesn't play.

This works on Chrome and Firefox working. How do I fix it for Safari?

回答1:

After looking at this problem elsewhere in some detail (see link below) I think the most likely reason is that Chrome and IE assume that the 'type=video/mp4' info in the HTML is correct and hence interpret the content returned from the server in this way, while Safari looks at the content type in the response to make its decision.

In other words, Chrome plays the returned file as video even though the HTTP response from the server has a header saying 'Content-Type:application/octet-stream' rather than 'Content-Type:video/mp4'.

You can check this by looking at the response headers for your example and seeing if the content type is set to 'application/octet-stream' rather than 'video/mp4'.

Related answer: https://stackoverflow.com/a/32967365/334402

回答2:

I've encountered the similar problem. In my case, it works well on Chrome and Firefox, or when I put an extension to the file. If I change mime type correctly, it still doesn't go through.

Actually I had a server we deployed return Response Header like the following.

HTTP/1.1 206 Partial Content
Date: Mon, 05 Mar 2018 08:33:49 GMT
Server: gunicorn/19.7.1
X-Powered-By: Express
content-type: video/mp4
accept-ranges: bytes
content-length: 2
content-range: bytes 0-1/37475549
Cache-Control: public, max-age=0
Connection: keep-alive

The Response Header itself is certainly correct.

However, there was a difference between the size which our server actually returned and content-length and content-range. So as of now, it works well because I fixed that. If you are in the same situation of mine, the bug will be reproduced with curl --range 0-1 <target URL>.

It will say like this error 18: transfer closed with outstanding read data remaining

So an answer is to confirm the values returned by your server properly.

Reference

curl error 18 - transfer closed with outstanding read data remaining

Does iPhone/iPad Safari require 'Accept-Ranges' header for video?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

https://github.com/WebKit/webkit/blob/5277f6fb92b0c03958265d24a7692142f7bdeaf8/LayoutTests/imported/w3c/web-platform-tests/fetch/http-cache/partial.html

https://github.com/w3c/web-platform-tests/blob/master/fetch/http-cache/partial.html

回答3:

Safari is extremely fussy when it comes to playback of streamed media such as video and audio. It has the following requirements

• The server/application hosting the media MUST support byte ranges. Safari will do a trial download of 2 bytes to ascertain the media length, it will then download the media in one or more chunks depending on the size of the file. It won't play nice if you just send it all the data.
• The content range returned from the media server must include a figure for total media size and not just "*".
• The media URL MUST have a suffix matching the type of media. It's like IE all over again: getting the mime type right is a fruitless exercise because Safari isn't going to follow the rules here and it will ignore mime type.

Note that Safari doesn't tell you what the problem is if it fails on playback, there's just a media error raised with no further information.

For mpeg 4 video / h.264, the suffix .mp4 works For mpeg 4 audio / aac, the suffix .aac works

If you are a Safari dev please consider fixing these things.

This is tested on Safari 11.1.2