Gzip issue with Safari

Server NGINX
1

Hi all,

we have successfully enable gziping on the server side and it works
perfectly with Chrome and FF (it auto compress the files that we want).
We’re using compressed assets of type: .dds and .pvr. MIME-types for
those
files are: application/octet-stream. But the problem appears in Safari
which
doesn’t accept .gz file type extension, so we are left out with a huge
improvement regarding file size/loading time.
Those are our current settings for enabling gzip:
gzip on;
gzip_proxied any;
gzip_types image/png application/javascript
application/octet-stream
audio/ogg text/xml image/jpeg;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1100;
gzip_static on;

I noticed that Apache server enables something like this:
AddEncoding gzip .jgz
AddType text/javascript .jgz

And this little change enables that Safari acknowledge gzip type and it
also
uploads it.
So the question is what are the possibilities on Nginx? Can we somehow
add
support for additional extensions?
I’ve also read something about gzip_static setting which look for
pre-compressed files, but it looks just for files with .gz extensions.
Do you know any solutions?

Posted at Nginx Forum:

2

Have you had a look yet at /conf/mime.types

Posted at Nginx Forum:

3

Could you be a little more specific? I have the right configuration on
nginx
regarding pvr and dds types, it’s: application/octet-stream…how could
I
modify the gzip extension to something else than .gz?

Posted at Nginx Forum:

4

On Mon, May 16, 2016 at 06:06:21AM -0400, mcofko wrote:

Hi there,

I confess I am not at all sure what it is you are asking about.

If it is clear to others who can help you, then there is no need for you
to do anything; but if it is generally unclear, perhaps you could
describe
again what you do, what you see, and what you want to see instead?

we have successfully enable gziping on the server side and it works
perfectly with Chrome and FF (it auto compress the files that we want).

This seems to say that in FF you request /one.dds, and your nginx
returns
a gzip-compressed version on the file one.dds. (And nginx compresses it
afresh on each request.)

We’re using compressed assets of type: .dds and .pvr.

This seems to say that in FF you request /one.dds, and your nginx
returns the contents of the pre-compressed file one.dds.gz.

I suspect that I am misunderstanding something.

But the problem appears in Safari which
doesn’t accept .gz file type extension,

And this bit, I’m not sure what it is intended to mean. In Safari you
request /one.dds, and nginx returns something other than the content of
the file one.dds? Or it returns the content, but Safari does not like
it for some reason?

    gzip on;
    gzip_proxied any;
    gzip_types image/png application/javascript application/octet-stream

audio/ogg text/xml image/jpeg;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1100;

That all says “sometimes, compress the response before sending it to
the client”.

    gzip_static on;

That says “if possible, send a pre-compressed file instead of the
uncompressed file”.

I noticed that Apache server enables something like this:
AddEncoding gzip .jgz
AddType text/javascript .jgz

I think that that sets some response headers, depending on what the
request was.

And this little change enables that Safari acknowledge gzip type and it also
uploads it.
So the question is what are the possibilities on Nginx? Can we somehow add
support for additional extensions?

What request do you make in Safari?

What response (http headers) do you get to that request?

What response do you want to get instead?

If you know that an Apache returns the response that you want, then
showing that output might answer the third question.

Alternatively, if Apache or nginx change their response based on the
User-Agent, you can try using “curl” to make the requests, using varying
User-Agent headers.

Do you know any solutions?

Not yet; I don’t know what the problem is.

Good luck with it,

f

Francis D. [email protected]

5

On Wed, May 18, 2016 at 03:37:51AM -0400, mcofko wrote:

Hi there,

enabled gziping on nginx and it’s working on Chrome perfectly (we know this
looking at network tab in developer tools, where we can see the size of the
gzipped file one.dds that needed to be downloaded and it’s around 2MB while
the original one.dds filesize is around 4MB).

I think this means that you can see the http request that Chrome makes,
and you can see the response that nginx gives, and that they are what
you want.

Can you use “curl” to make the same request, and see the same
response? That usually makes it easier to see what exactly is going on,
because there are fewer layers in the way.

(I’m not sure whether your nginx is serving the content of the file
one.dds.gz as-is, or is serving the content of the file one.dds and
gzip’ing it on-the-fly. Maybe it makes a difference; maybe it doesn’t.)

I also checkede the header of
the file, and Accept-Encoding has values GZIP, deflate, sdch.

I think that that refers to the http request header; with luck you
will be able to reproduce that in curl, where the full communication
can be copy-paste’d.

But the same file loaded on iMac with Safari browser takes/loads 4MB, which
clearly states that the Safari somehow doesn’t accept or ignores files with
.gz extension. I also checked file header and Accept-Encoding has: GZIP,
deflate.

Can you see the differences between the request that Chrome made and
the request that Safari made? That might indicate why nginx gave
different
responses.

If you can re-create both requests in curl you’ll be able to see the
different responses from your nginx, and maybe that will give you a hint
as to where the problem is.

The same problems were already reported on some other forums, but they were
able to solve the problem, because they’re using Apache, which enables
adding options as:
AddEncoding gzip .jsz
AddType text/javascript .jsz

I don’t see those other forums you mention.

I don’t see that those options will make a difference unless you are
actually requesting /one.jsz or /one.dds.jsz. But perhaps there are
extra things happening in the apache config that makes things work.

nginx does have an add_header directive to add general headers; and has
a types directive to set one header based on filename extension.

It may be that some combination of those could help you; but I suspect
that the full answer will be different.

I hope this links will help you understand my problem:
Safari: don’t give gzipped content a .gz extension – BigSmoke

They seem to say that you shouldn’t ask Safari to request /one.js.gz if
you want Safari to use the response as a script.

That doesn’t seem related to the rest of your email.

I suspect I’m missing something.

And I still don’t know what request you make, what response you get,
or what response you want. So I’ll let someone else get involved.

Cheers,

f

Francis D. [email protected]

6

Let me try to explain it a little more detailed.

My main problem: “But the problem appears in Safari which
doesn’t accept .gz file type extension”, which means although we have
enabled gziping on nginx and it’s working on Chrome perfectly (we know
this
looking at network tab in developer tools, where we can see the size of
the
gzipped file one.dds that needed to be downloaded and it’s around 2MB
while
the original one.dds filesize is around 4MB). I also checkede the header
of
the file, and Accept-Encoding has values GZIP, deflate, sdch.

But the same file loaded on iMac with Safari browser takes/loads 4MB,
which
clearly states that the Safari somehow doesn’t accept or ignores files
with
.gz extension. I also checked file header and Accept-Encoding has: GZIP,
deflate.

The same problems were already reported on some other forums, but they
were
able to solve the problem, because they’re using Apache, which enables
adding options as:
AddEncoding gzip .jsz
AddType text/javascript .jsz

I hope this links will help you understand my problem:
http://blog.bigsmoke.us/2012/01/16/safari-ignores-content-type-for-gz-suffix

regards,
m

Posted at Nginx Forum: