I'm developing a website, I'm using gzip.exe to pre-compress css and js files (it's only 1 css file that went from 4.53 KB to 1.50 KB, and a js file containing the jquery and some scripts that went from 72.8 KB to 24.7 KB)
these files are style.gz and js.gz and served as static files.
The problem is that they don't work with Safari (v5.0.2) not the css neither the js.
the work fine for these browsers:
Firefox 3.6.10 / Google Chrome 6.0.4... / IE 8 x64 / Flock 3.0.6 / Maxthon 2.5.15... / Avant Browser 2010
All of them work fine except Safari
I'm using Windows 7 x64
You should get the server to gzip them - this can be done in the htaccess file and works just fine.
+1 What rob said.
What you're doing is a hack that is not supposed to work, so you can't really complain when it fails. Serving a gzip resource is completely different to serving a resource with a different type using a Content-Encoding header to compress it on the wire.
Serving pre-gzipped files will obviously also fail for user agents that don't understand gzip. The HTTP standard provides a mechanism for negotiating this: Accept-Encoding and Content-Encoding. Unless you re-implement that mechanism in a complete, standard-compliant way (and the article in Michael's link doesn't begin to get that right), you're blocking clients.
This is all unnecessary. Gzip is fast and servers typically cache the compressed version of static content so you gain nothing by trying to second-guess it. HTTP compression is part of the web server's core competency, let the web server do its job and leave gzip alone.
There is a way around this issue. Basically, you need to use .jgz instead of .gz as the extension for JavaScript files:
Fix for .gz and Safari
Related
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 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>
Using Litespeed I have found that connections for javascript files are not being kept alive, but they are for jpeg and css files.
Using Firebug. Looking at the connection request headers for javascript files shows keep-alive
Looking at the connection response headers for javascript files shows close.
I have looked at the documentation for Litespeed and nowhere can I find a setting to disable keep-alive for javascript files.
Any and all suggestions gratefully received.
Sorted!
Litespeed have just issued a patch. Connections for Javascript files are now kept-alive.
I am new at using GZIP.
I'm using a Wordpress plugin that GZIP the website but I ran the Google Speed test and it says that the website is not gzipping bootstrap .less files and the javascript files that I call.
I'm not sure how to call a gzip or even making one, can somebody help me?
Javascript should be served minified and after minification both JS and CSS should be served compressed. Have a look at How to 'minify' Javascript code
If you are using apache 2.* as your web server you could enable mod_deflate. You can then configure the module to compress .less and any other static content you want to compress.
Here is a link to the documentation for the module: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
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.