Forum: NGINX about add deflate support to http_gzip_filter_module

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Paul G. (Guest)
on 2008-12-30 04:22
(Received via mailing list)
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?
unknown (Guest)
on 2008-12-30 09:03
(Received via mailing list)
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. :)
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." <removed_email_address@domain.invalid>
Date: Monday, December 29, 2008 6:13 PM
To: <removed_email_address@domain.invalid>
Subject:  about add deflate support to http_gzip_filter_module
Kinch Zhang (Guest)
on 2008-12-30 21:21
(Received via mailing list)
<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.
This topic is locked and can not be replied to.