Is there any way to make Substitution module to work with gzip?

Server NGINX
1

Substitution module http://wiki.nginx.org/NginxHttpSubModule can replace
text for content from proxy_pass.

In order to use this function, it have to turn gzip transfer off from
server
to server, which is understandable all right.

But I want when after substitution module replaced the text, nginx can
gzip
it and send it to client. Is there any way to do that?

here is my sample conf

location /source {
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://source;
proxy_set_header Accept-Encoding “”;
sub_filter_types text/xml;
sub_filter ‘3236699304584559’ ‘9418887123196030’ ;
sub_filter_once off;
break;
}

2

Hello!

On Fri, Jan 29, 2010 at 04:25:33PM +0800, tOmasEn wrote:

Substitution module http://wiki.nginx.org/NginxHttpSubModule can replace
text for content from proxy_pass.

In order to use this function, it have to turn gzip transfer off from server
to server, which is understandable all right.

But I want when after substitution module replaced the text, nginx can gzip
it and send it to client. Is there any way to do that?

Just use gzip filter as usual.

Maxim D.

            sub_filter_types text/xml;
            sub_filter '3236699304584559'  '9418887123196030' ;
            sub_filter_once off;
            break;

}

–
Tomasen
http://twitter.com/ShooterPlayer
Sina Visitor System

3

tOmasEn at 2010-1-29 16:25 wrote:

Substitution module http://wiki.nginx.org/NginxHttpSubModule can
replace text for content from proxy_pass.

In order to use this function, it have to turn gzip transfer off from
server to server, which is understandable all right.

But I want when after substitution module replaced the text, nginx can
gzip it and send it to client. Is there any way to do that?
Are you sure Nginx can’t gzip the response with the substitution
module? AFAIK, the substitution module is a filter module before the
gzip filter module. They are not conflicted.

–
Weibin Y.

4

maybe because of mixed with proxy pass?

I use curl to test:

this is the server mix proxy_pass with substitution with gzip on:
curl -k “Host: www.shooter.cn” “http://124.155.161.176/xslt/main.xsl”
-vvv -o x --compressed
return 51k none-gziped content

this is the original serverwith gzip on:
curl -k -H “Host: www.shooter.cn” “http://61.129.66.75/xslt/main.xsl”
-vvv -o x --compressed
return 15k gziped content

5

by the way I also tried add gzip_proxied any;, but doesn’t make
difference.

         location = /xslt/main.xsl {
            proxy_set_header  X-Forwarded-For

$proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://61.129.66.75:80;
gzip_proxied any;
proxy_set_header Accept-Encoding “”; //have
to
use this otherwise sub_filter won’t work
sub_filter_types text/xml;
sub_filter ‘3236699304584559’
‘9418887123196030’ ;
sub_filter_once off;

        }
6

tOmasEn at 2010-1-29 17:21 wrote:

                    proxy_set_header    Accept-Encoding ""; //have

to use this otherwise sub_filter won’t work
This directive deletes the request’s "Accept-Encoding " header and the
gzip module will not work any more.

You may use this module to set the input header:

more_set_input_headers ‘Accept-Encoding: gzip’;

But I suggest you should turn off the gzip in the backend instead, it’s
more clear than these trick directives.

                    sub_filter_types text/xml;
                    sub_filter '3236699304584559'

‘9418887123196030’ ;
sub_filter_once off;

        }

–
Weibin Y.

7

Hello!

On Fri, Jan 29, 2010 at 06:49:44PM +0800, Weibin Y. wrote:

                   gzip_proxied any;

Directive gzip_proxied isn’t relevant here. It only relevant if
request was got from proxy server (determined based on Via header
presense in request).

                   proxy_set_header    Accept-Encoding "";

//have to use this otherwise sub_filter won’t work
This directive deletes the request’s "Accept-Encoding " header and
the gzip module will not work any more.

No. This directive doesn’t pass Accept-Encoding header to
upstream, but it has nothing to do with original request headers.

The reason why gzip filter doesn’t work is quite simple: it isn’t
configured to do so.

Key things that should be configured in this case are:

gzip on;
gzip_types text/xml;

Note well: when testing with console downloaders it is quite
possible that they use HTTP/1.0. In this case one also required
to set

gzip_http_version 1.0;

but it’s not generally good idea to do so in production as modern
browsers use HTTP/1.1, while HTTP/1.0 clients may handle gzip
incorrectly (and that’s why gzip is disabled for HTTP/1.0 clients
by default).

Full details may be found here:

http://wiki.nginx.org/NginxHttpGzipModule

Maxim D.