About add deflate support to http_gzip_filter_module

Server NGINX
1

I have a suggestion on improving http_gzip_filter_module and want to
discuss
with you:

Currently most browsers support both the gzip and deflate compression
methods,
and the algorithms of gzip and deflate are almost the same,
except that the deflate compression removes an 18 bytes header.

In order to save bandwidth, I hope to add a ‘gzip_deflate’ option which
could
support deflate compression when enabled. Default value is Off.

Any ideas?

2

My readings of the applicable RFCs (2616, 1950, 1951, and 1952) indicate
that you can’t just “strip” the header off a proper RFC-compliant gzip
stream and call it “deflate”. The “gzip” compression is a RFC 1952 gzip
stream which may contain one or more members. The “deflate” compression
is
an RFC 1950 zlib + RFC 1951 deflate stream, which differs from a “raw”
RFC
1951 DEFLATE stream.

I realize that many popular web servers simply send a RFC 1951 stream,
but
in my opinion, if it’s added to nginx, it ought to be done right. :slight_smile:
I’ve
not looked at the relevant code yet, but getting a zlib stream instead
of a
gzip stream should be easy enough, in the end.

Also, due to the fact that a zlib stream is “simpler” than a gzip
stream,
many implementations of zlib are actually faster (though potentially a
tiny
bit larger in terms of total data). So, instead of a separate
‘gzip_deflate’
directive, I’d like to see it implemented as “always on” (in case a User
Agent only requests deflate for some reason). Then the gzip directive
could
be modified to have 3 options: Off; On (same as ‘prefer_gzip’); and
‘prefer_deflate’ (for those sites which prefer the efficiency over the
potential < 10% bandwidth savings). Potentially, there could also be a
‘never_deflate’ option to the gzip directive. Honestly, I can’t see a
huge
reason for this, myself.

By changing the gzip directive, any upgrading sites would
“automagically”
get the new feature while allowing sites to fine-tune their outgoing
content. And all without yet-another-directive. And it could be
documented
akin to gzip_proxied:

gzip

syntax: gzip off|prefer_gzip|prefer_deflate|on

default: gzip off

context: http, server, location, if (x) location

Enables or disables gzip compression.

  • off - disables compression for all requests
  • prefer_gzip - sends gzip content to user agents who can accept both
    gzip and deflate content
  • prefer_deflate - sends deflate content to user agents who can
    accept
    both gzip and deflate content
  • on - synonym for “prefer_gzip”. For backwards-compatibility with
    older
    versions

But count this as a message in support of the feature (else I would not
have
bothered typing so much). I’d just like to see it implemented in a way
that
is as useful as possible, and without mimicing “other” web servers’
buggy
behaviors.

Warmest,

–Matt

From: “Paul G.” [email protected]
Date: Monday, December 29, 2008 6:13 PM
To: [email protected]
Subject: about add deflate support to http_gzip_filter_module

3

<matt@…> writes:

Enables or disables gzip compression.

  • off - disables compression for all requests
  • prefer_gzip - sends gzip content to user agents who can accept both
    gzip and deflate content
  • prefer_deflate - sends deflate content to user agents who can accept
    both gzip and deflate content
  • on - synonym for “prefer_gzip”. For backwards-compatibility with older
    versions

This is even better, and I hope this feature could be implemented in the
near
future.