Storing my photos on AWS and serving them with Cloudflare.
Cloudflare serves all phtos as WebP. But some of browsers that don't support WebP, can not see my images. So that is a seriously problem for me.
Couldn find any configuration with that situation. How can I disable webp convertation? Or can I make It dynamically (firstly I define my visitor's browsers, then I show em WebP image, or not WebP image)
There are at least a couple settings that could affect this. They are under the "Speed" page on the "Optimization" tab of the Cloudflare Dashboard.
Image Resizing
Polish
Both these could be converting images to WebP format. However, in theory, they should only serve this format when the client / browser supports it.
You can turn off these settings and it should result in a quick fix, but I would also reach out to Cloudflare support with details on the clients you are seeing errors with.
Related
we're using a couple of hundreds Hikvision Cameras (DS-9664NI-I8) for a University. We want to embed them to a web page hosted locally. Cameras, NVR, and webpage are on same local network.
We don't want to use RSTP, we will use HTTP.
We're able to run the camera sub-stream on the browser using the following URL
http://<username>:<password>#<IP Address>/Streaming/channels/102/httpPreview
But, when I embed this to image src, this won't work, as browsers don't support the HTML embedded credentials.
How to play the camera streams on the web page?
You can disable security on streams. But if it possible - that depends on your camera and its firmware version. And be aware of consequences of course, secure your image with another means - firewall, etc.
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>
Below are two screenshots from the same version of Chrome. I would like to know when and why header names sometimes are displayed with different word capitalization and also when is the view source/view parsed toggle available? I've read the developer tools documentation which says nothing about it and tried to load pages in different ways. The only pattern i suspect is content compression, could that be it?
Update: nope seen both versions on sites using gzip
It seems that it happens only for resources served over HTTP2/SPDY (compare this image served over HTTP2 with the same image served over HTTP). There is an old Chrome bug that proves that HTTP2/SPDY headers are being handled differently. I reported this as a bug here.
I installed an SSL Certificate which required me to switch all HTTP Links over to HTTPs links. I did this by downloading all site files (including the database) and did a find/replace, thus replacing all http:// with https:// then I uploaded the new site files (and .sql file) to the server. And everything appeared to be working. Except that .png images wont load in any browser.
I can't even pull up the image by typing in the direct link in the address bar (with or without the https). Previously the images worked fine, they now just show the red X.
Any ideas on what's going on and how can I fix it?
The site is built with Joomla 2.5. You can see it here: https://www.detourjournal.com/ (Note the two .png images in the footer that are not loading)
It's not your Joomla! setup, for starters it doesn't appear to be Joomla! redirecting calls to SSL in normal pages and it doesn't affect direct file URL for images this way.
You appear to have configured your server to force https (possibly via .htaccess).
It's also not specific to PNG files as your logo, /images/stories/logo2.png is being served without a problem. The same goes for the PNG's in VirtueMart e.g. the close label.
Looking at the header for those images the sizes don't match what is being returned... so it's most likely corrupt images cause Apache to bork.
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.