Ssi includes in reverse-proxied pages?

Server NGINX
1

hello,

Quick question: is it possible for nginx to parse SSI directives in
pages retrieved from upstream? I have a front end that proxies to both
a rails CMS and a shop application and I’d like to include partials
from one in the other, but so far I can only get SSI working in the
static files that are served directly by nginx.

thank you,

will

2

On 22.08.2008 13:23, William Ross wrote:

Quick question: is it possible for nginx to parse SSI directives in
pages retrieved from upstream?

Yes, it possible. Just add ssi on; in location with proxy_pass.

3

On 22 Aug 2008, at 10:41, Anton Y. wrote:

On 22.08.2008 13:23, William Ross wrote:

Quick question: is it possible for nginx to parse SSI directives in
pages retrieved from upstream?

Yes, it possible. Just add ssi on; in location with proxy_pass.

Thank you. That’s what I’ve been doing, but so far it’s not working.
The proxy works, and SSI works in local files, but together they don’t
work. The SSI directives pass through untouched, so it looks like the
upstream pages are not parsed but travel straight through, but the
debug log does include a few lines like this:

2008/08/22 16:14:26 [debug] 436#0: *34 finalize http upstream request: 0
2008/08/22 16:14:26 [debug] 436#0: *34 finalize http proxy request
2008/08/22 16:14:26 [debug] 436#0: *34 free rr peer 1 0
2008/08/22 16:14:26 [debug] 436#0: *34 close http upstream connection:
38
2008/08/22 16:14:26 [debug] 436#0: *34 http upstream temp fd: -1
2008/08/22 16:14:26 [debug] 436#0: *34 http output filter “/?”
2008/08/22 16:14:26 [debug] 436#0: *34 copy filter: “/?”
2008/08/22 16:14:26 [debug] 436#0: *34 http ssi filter “/”
2008/08/22 16:14:26 [debug] 436#0: *34 ssi out: 000000000059EEB0
0000000000000000

The page is gzipped upstream. Would that stop the proxy parsing the
pages?

thanks,

will

4

On 22.08.2008 19:22, William Ross wrote:

The SSI directives pass through untouched, so it looks like the upstream
2008/08/22 16:14:26 [debug] 436#0: *34 http ssi filter “/”
2008/08/22 16:14:26 [debug] 436#0: *34 ssi out: 000000000059EEB0
0000000000000000

The page is gzipped upstream. Would that stop the proxy parsing the pages?

Page should be not compressed AFAIK.
To tell upstream don’t compress page you may add

proxy_set_header Accept-Encoding “”;

or better change gizp related settings on upstream server.

5

On 22 Aug 2008, at 16:36, Anton Y. wrote:

On 22.08.2008 19:22, William Ross wrote:

On 22 Aug 2008, at 10:41, Anton Y. wrote:

On 22.08.2008 13:23, William Ross wrote:

The page is gzipped upstream. Would that stop the proxy parsing
the pages?

Page should be not compressed AFAIK.
To tell upstream don’t compress page you may add

proxy_set_header Accept-Encoding “”;

the upstream server is out of my control, but the Accept-Encoding
header is a very neat solution and it works perfectly. thank you.

will

6

On Fri, Aug 22, 2008 at 04:22:26PM +0100, William Ross wrote:

work. The SSI directives pass through untouched, so it looks like the
2008/08/22 16:14:26 [debug] 436#0: *34 copy filter: “/?”
2008/08/22 16:14:26 [debug] 436#0: *34 http ssi filter “/”
2008/08/22 16:14:26 [debug] 436#0: *34 ssi out: 000000000059EEB0
0000000000000000

The page is gzipped upstream. Would that stop the proxy parsing the
pages?

Yes, upstream response must not be compressed.