I am trying to figure out why an MP4 video is not working on our server only in Safari 9.
I have tried the video on my local device and it plays just fine on the website using the same version of Safari.
It appears to only not be working in Safari 9 on the server. I believe all the MIME types are setup on the server because the video works on other browsers.
The site is behind Cloudflare and I have tried using a file rule on .mp4 for Cloudflare to ignore and not serve that file.
Any ideas on what else I can try to get this fixed in Safari?
I'm trying to resolve a similar issue myself. I found the following SO piece that might help? Safari 9.0 can not play mp4 video on the storage server
In summary Safari doesn't make a full Range request in the header, unlike Chrome and other browsers. As a result it doesn't know how to interpret the response.
Further reading suggests that Apple requires HTTP servers to support byte range requests. https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6
It also looks like Apache <= 2.2.20 surfed a DoS exploit back in 2011 with Range Headers and were subsequently disabled by default. http://httpd.apache.org/security/CVE-2011-3192
I also think the issue is with Cloudflare. The mp4 from my tags are working on all browsers, except Safari. Once Cloudflare has been paused, the videos work on Safari too. Resuming Cloudflare recreates the issue.
If your server is Apache try placing this in .htaccess
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|mp4|ogv|webm)$ no-gzip dont-vary
This solved videos not loading for me in Safari on a domain with Cloudflare enabled.
I think it's related to video or music content that needs to stream and based on CloudFlare must move to a subdomain like cdn.domain.com
Sites that do streaming content, however, should move their streaming
content to a subdomain we don't proxy in their DNS settings.
link
My Cloudflare isn't returning the Accept-Ranges header and so Safari won't play back my .mp4 files, regardless of size. Tried quite a few of the suggestions above without success. What finally worked was adding the missing header in via the .htaccess file.
<IfModule mod_headers.c>Header add Accept-Ranges "bytes"</IfModule>
Related
I am displaying a video with the html5 video element. The source is a pre-signed url from Wasabi s3. It works well on Chrome but it won't play on Safari. I did some research and it seems like this is usually due to the server not being configured to return a 206 code. However, I did check the server and it seems to support byte-range requests.
Here is the network tab. Any help would be greatly appreciated.
Ok, it seems like I usually get stuck on those minuscule problems. Turns out that Safari, unlike Chrome, doesn't like to play files without file extension. Adding ".mp4" to my files solved the problem...
I built an image resize script to resize the requested image and return it with PHP. However I would like to cache the requested images.
I tried to built some .htaccess rules and realized cache-control is not working in safari for me. Safari caches .css files, etc. automatically but does not cache images. I do not have any website specific developer tools active, and tested this in a blank environment with an extra subdomain with only a .htaccess and a .jpeg file.
My .htaccess code looks like:
Header set Cache-Control "max-age=10800,private"
With nothing else in it which should force all files to be cached for 3 hours. With Chrome however this works as expected and caches the files. Server returns a http header 304 telling the client to load the file from the cache.
Taking a look at the safari file informations in the developer menu, I can see the Cache-Control settings are received well (Cache-Control: max-age=10800,private) but on each reload safari shows a http 200 response without any cached files and loads the image again.
Are there any known issues with safari cache control? I searched the web but did not find anything and my web hosting provider told me caching is nothing browser specific on server side.
I ran into a really weird issue this morning when trying to access a web app I'm building using an iPad (Safari Mobile/Webkit). On the front end, the web app relies heavily on XHR/Ajax requests. On the back end, the server is configured to gzip compress responses if the "Accept-Encoding" includes "gzip".
Everything was working great until I flipped the server to SSL. Then I started getting intermittent "CFURLErrorDomain:303" errors in Safari.
After a quick search I found this link:
http://beyondrelational.com/modules/2/blogs/45/posts/12034/failed-to-load-resource-safari-issue.aspx
According to the link, Safari requires a content-length header when making XHR (ajax) request over SSL/HTTPS. In my case, the server is gzipping content directly to the output stream so I have no way of knowing what the final content length will be.
As a workaround, I added the following logic on the server:
if (request.isEncrypted()) gzip =
!request.getHeader("User-Agent").toLowerCase().contains("webkit");
In other words, if the connection is encrypted via SSL, and the browser is some webkit derivative (e.g. Safari, Chrome, etc), then don't compress the output. This seems to work but it really slows things down.
So my question is this:
Does Safari support gzip compressed responses over SSL or am I barking up the wrong tree?
Turns out the error I was seeing was a bug in the server and nothing to do with Safari. The server was relying on chunked transfer encoding when compressing large byte arrays. Individual "chunks" were broken up into pieces (header, body, trailer) and sent to the client in separate messages. The SSL client (safari) was expecting one contiguous "chunk" so it didn't know what to do when it saw an incomplete chunk. The server has been patched and the issue is now resolved.
I have a problem with embedding SWFs via SSL.
I know that the common misconception with embedding SWFs on secure pages is that people always try to embed it using a non-secure link. This isn't the case, as I am trying to host the SWF and swfobject.js locally using relative paths to account for the use of SSL.
It appears that the first of these players (under ssl) will play the audio playback, but won't display the video, while the second one will render the entire SWF fine.
Here are 2 examples that are EXTREMELY similiar. Unfortunately I can only post 2 hyperlinks, so you'll have to swap the http: protocol with https: to see how each player renders under SSL.
These 2 players are using 2 different SWF's, so I'm lead to believe it's a Flash/ActionScript issue, but I have failed to isolate it.
Example 1
Non-secure working embed
Example 2
Non-secure working embed
First, Mixed http & https are different domains that run afoul of the Adobe Flash Player's same-domain security restriction. Using a cross-domain file on the root of your server will allow access.
Second, IE has some known problems with SWF and SSL.
Third, be sure to enable https and check to ensure you have a valid root certificate.
Without more information, this is the best I can do.
The best way is to test your work using the Debug Version of Flash Player. This works best in Firefox. Chances are there is something (dependency or resource) that the player is trying to get without SSL.
I just installed MediaWiki on a website and I am having some problems.
Whenever I go to "www.something.com/wikidir" the server gives me the PHP index file as an unnamed download instead of displaying it.
However, if I go to "www.something.com/wikidir/index.php" everything works as expected.
I'm not familiar with Apache and was wondering if someone could tell me how to fix this or point me in the right direction?
I'm using a LAMP stack and Mediawiki 1.7.1 (old I know).
In my .htacces file I have:
AddType application/x-httpd-php5 .php
Sounds like Apache (or PHP?) is serving the page as an application/octet-stream. You can check this by looking at the response headers on the non-index.php page. Firefox can do this using the Web Developer Toolbar > Information > View Response Headers. Look for "Content-Type"
Or, Does the non-index.php link work in IE? Does it go straight to download in Firefox (or another browser)? If the answer is yes, that's the problem.
How to fix it is more complex because there could be a bunch of different things that are causing this. My guess is that's it's an Apache config issue.
Edit
Check your .htaccess file. Make sure it's readable by Apache. I bet that's the issue.