Can't activate gzip to work accurate in Safari/Chrome

Server NGINX
1

Hello!
I’m using nginx/0.8.38 and like to use the gzip for the many js and css
files on my page. Everything works great in FF, but Safari and Chrome
downloads the files never gzipped - even if there is a gzip in the
“content-Encoding:gzip” in the header.
My nginx gzip config in the server {} part of the site:

    gzip              on;
    gzip_buffers      16 8k;
    gzip_comp_level   9;
    gzip_http_version 1.1;
    gzip_proxied      off;
    gzip_min_length   0;
    gzip_types        text/plain text/css image/x-icon image/bmp

application/x-javascript application/javascript application/json;
gzip_vary on;
gzip_disable “MSIE [1-6].”;

i don’t know what I can do.
I would love to have a solution!
Thanks

Posted at Nginx Forum:

2

If you want to check the difference:
http://www.bong.tv/jquery/de/2.5/javascript-packed.js => FF = 168kb
http://www.bong.tv/jquery/de/2.5/javascript-packed.js => Safari or
Chrome = 609kb

Thanks for any help!!

Posted at Nginx Forum:

3

On Tue, Jun 08, 2010 at 10:44:38AM -0400, bongtv wrote:

If you want to check the difference:
http://www.bong.tv/jquery/de/2.5/javascript-packed.js => FF = 168kb
http://www.bong.tv/jquery/de/2.5/javascript-packed.js => Safari or Chrome = 609kb

How did you see 609K ?
I’ve tried http://www.rambler.ru in Chrome and Safari Developer tools
consoles, and it showed ~100K while in access log I see only 33K.
FF in Page Info shows 33K.

–
Igor S.
http://sysoev.ru/en/

4

I used the developer tools built in in the browsers. If there is a
compression made you will see this in the ressources pane of the
developer tools. In the example above you see that the browser loads the
full file. We made a transition from apache to nginx and we found this
out because useres wrote us about longer loading times.

Posted at Nginx Forum:

5

You need to set last-modified headers. Check push module documentation.

Sergej

6

Hello,

im am running nginx 0.8.38 with nginx_http_push_module. I receive all
new
messages more than one time… I receive the messages 5 secounds (this
is my
push_message_timeout time) so i think, the push module does not know
that the
message is allready received… How knows the push_module that the
message
is already sent to one client?

Any ideas how i can fix my setup, so that each client receive the
message only once time.

This is my setup:

           location = /broadcast/sub {
                default_type  text/json;
               set $push_channel_id $arg_channel;
               push_subscriber;
               push_subscriber_concurrency broadcast;
               push_channel_group broadcast;
           }

           location = /broadcast/pub {
               set $push_channel_id $arg_channel;
               push_publisher;
               push_min_message_buffer_length 5;
               push_max_message_buffer_length 20;
               push_message_timeout 10s;
               push_channel_group broadcast;
           }

I send new messages with curl

 $ch = curl_init($pub_url);
 $data = array('status' => $message);
 curl_setopt($ch, CURLOPT_HTTPHEADER, Array("Content-Type:

text/json"));
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$return = curl_exec($ch);
curl_close($ch);

Thanks for any hints…

Alexander

//
///
///

7

On Tue, Jun 08, 2010 at 02:04:04PM -0400, bongtv wrote:

I used the developer tools built in in the browsers. If there is a compression made you will see this in the ressources pane of the developer tools. In the example above you see that the browser loads the full file. We made a transition from apache to nginx and we found this out because useres wrote us about longer loading times.

Safari/Chrome developer tools do not show correct size information.
Try to look sizes in access_log.

–
Igor S.
http://sysoev.ru/en/

8

On Tue, Jun 8, 2010 at 1:22 PM, Igor S. [email protected] wrote:

On Tue, Jun 08, 2010 at 02:04:04PM -0400, bongtv wrote:

I used the developer tools built in in the browsers. If there is a compression made you will see this in the ressources pane of the developer tools. In the example above you see that the browser loads the full file. We made a transition from apache to nginx and we found this out because useres wrote us about longer loading times.

Safari/Chrome developer tools do not show correct size information.
Try to look sizes in access_log.

Or use Fiddler if you’re testing Windows browsers (www.fiddler2.com).
It acts as a debugging proxy, and shows you the entire conversation,
with lots of useful tools. I find it better than Firebug for tracking
down HTTP-layer issues, because as a proxy it supports any browser, or
even web services clients. It can also act as a “man in the middle” on
SSL connections too (with certificate warnings of course).

–
RPM

9

Hello!

On Tue, Jun 08, 2010 at 02:04:04PM -0400, bongtv wrote:

I used the developer tools built in in the browsers. If there is
a compression made you will see this in the ressources pane of
the developer tools. In the example above you see that the
browser loads the full file. We made a transition from apache to
nginx and we found this out because useres wrote us about longer
loading times.

Chrome reports uncompressed size in developer tools instead of
on-wire (compressed) one. Most likely Safari does the same thing.
Use tcpdump instead.

Maxim D.

10

Thanks a lot Sergej, thats it.

11

Hello!

On Tue, Jun 08, 2010 at 02:27:17PM -0500, Ryan M. wrote:

with lots of useful tools. I find it better than Firebug for tracking
down HTTP-layer issues, because as a proxy it supports any browser, or
even web services clients. It can also act as a “man in the middle” on
SSL connections too (with certificate warnings of course).

Using Fiddler is not really an option when you are debugging http
protocol (even on Windows where it only works). It’s http proxy,
and this changes things a lot - browsers use another code pathes,
Fiddler itself handles hop-by-hop headers and so on.

In simple cases it will work (including this one), but please keep
in mind it’s not perfect (and can’t be).

Maxim D.

12

Addition: I think the only difference is the missing
“Content-Length” in the header of the file in the newer nginx version.

Posted at Nginx Forum:

13

Hi everyone. First of all thanks a lot for your help and answers. I run
another test, because we had many requests from our clients… (with
Safari) … that the site seems to be slower. I run a test locally with
a older version of nginx: 0.6.34 => with this version the gzip shows up
correctly in the WebDeveloper of Safari and Chrome. For this reason i
suggest, that it is a nginx topic, not a bug or view problem of the
web-developer tools built in.

Perhaps you have andy idea. Thanks in advance.

Posted at Nginx Forum:

14

On Fri, Jun 18, 2010 at 07:19:34AM -0400, bongtv wrote:

Addition: I think the only difference is the missing
“Content-Length” in the header of the file in the newer nginx version.

nginx always removes “Content-Length” if a response is gzipped.
So was since 0.1.0 version.
The only exception is gzip_static, when nginx sends already gzipped
file.

–
Igor S.
http://sysoev.ru/en/

15

On Tue, Jun 8, 2010 at 4:05 PM, Maxim D. [email protected] wrote:

Using Fiddler is not really an option when you are debugging http
protocol (even on Windows where it only works). Â It’s http proxy,
and this changes things a lot - browsers use another code pathes,
Fiddler itself handles hop-by-hop headers and so on.

In simple cases it will work (including this one), but please keep
in mind it’s not perfect (and can’t be).

Fiddler can work as a reverse debugging proxy in front of nginx too,
eliminating the concerns about the browser using different code paths.
Your worries about hop-by-hop headers would still likely apply,
though.

–
RPM