Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are going to be running a nginx reverse proxy that will pull data from a backend via the internet.

What we mean by via the internet is the backend machine will not be on a lan with the front facing reverse proxy.

We were thinking it would be nice to grip these requests prior to sending them over the internet.

The way I see it it should work something like this:

Client requests content with a accept-encoding header or gzip.

Reverse proxy sends this to the backend server.

Backend compresses this content since a accept encoding header of gzip was sent.

Request sent all the way up the chain compressed.

This we can all do as its pretty straight forward. The question I have is how will this work if we have gzip compression enabled on the nginx reverse proxy side?

Will nginx try to gzip content that is already gzipped?

Hope this makes sense. Thank you.

UPDATE 1:

I understand the implications of caching already (and this serving) gzipped content. We would modify the cache key to include the accept encoding header, and thus serve (and cache) the properly compressed / uncompressed content according to what the user agent can accept.

share|improve this question
    
I don't think this question fits the site very well. The setup you're describing is hardly complex, just try it and see if it does what you expect. If not, try and make it do what you want with a little research and config tweaking, and if you still have questions, we're here. You've done almost no research of your own. –  ThatGraemeGuy Aug 22 '12 at 11:20
    
While I understand that the method posted above should work. I usually ask on here for clarification. Perhaps there is an automated way to have the proxy_pass module request backend content to be compressed? Perhaps there are any further gotchas that I have not though about? I think it wise to approach a problem with as much knowledge in hand as possible... Especially as our service is live, in production and fairly busy... Wouldnt want to start sending gzipped content to useragents that do not accept it. Or double gzipping content and wasting precious cycles... –  anonymous-one Aug 22 '12 at 11:25
add comment

1 Answer

up vote 1 down vote accepted

No, there is no problem with setting gzip on the reverse proxy and the backend server. At least I never had any issues. The proxy will recognize the already gzipped content and simply deliver it.

If you want any content to be gzipped from the backend simply add the appropriate header.

proxy_set_header Accept-Encoding "gzip";
share|improve this answer
    
We tested, and implemented gzipping on our backend. One note: proxy_set_header Accept-Encoding gzip is not recommended UNLESS you use (which we started) nginx gunzip (yes, its called gunzip) module. Other wise you will be serving gzipped content to clients which do not support compression. With gunzip module, you CAN use proxy_set_header Accept-Encoding gzip, and have nginx uncompress the content if required. –  anonymous-one Aug 26 '12 at 21:31
    
Since there are no other answers, I will correct answer this one as its largely correct. –  anonymous-one Aug 26 '12 at 21:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.