0

I'm using Nginx to act as an SSL proxy inside a docker container listening on port 443. The proxy correctly works and properly routes trafic to another Nginx instance upstream on port 80 (that lives inside another container).

I'm encountering mixed content issues, and I'm not sure what would be the proper fix:

A request aimed at a folder (but without the trailing slash) like: https://example.com/mediafiles/bar gets properly routed to the second NginX instance.

However it gets a 301 to an http url (response headers):

$ curl -IL https://example.com/mediafiles/bar

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 15 Jun 2015 15:16:29 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: http://example.com/mediafiles/bar/
X-UA-Compatible: IE=Edge,chrome=1

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 15 Jun 2015 15:16:29 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://example.com/mediafiles/bar/

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 15 Jun 2015 15:16:29 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1786
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Wed, 18 Mar 2015 23:09:35 GMT
Vary: Accept-Encoding
ETag: "550a05af-6fa"
Accept-Ranges: bytes
X-UA-Compatible: IE=Edge,chrome=1

Probably caused by this common try_files config (EDIT: apparently it's not issuing redirects).

location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ /index.php?$args;
}

I've posted the full upstream config here: https://gist.github.com/mgcrea/f149d0481ad1fa1c2207

And the relevant proxy config here: https://gist.github.com/mgcrea/26ef92026a20ccc22226

This 301 to an http resource triggers a mixed content error:

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource 'http://example.com/mediafiles/bar/'. This request has been blocked; the content must be served over HTTPS.

Any ideas?


Seems to be related: https://stackoverflow.com/questions/15555428/nginx-causes-301-redirect-if-theres-no-trailing-slash

Olivier
  • 415
  • 3
  • 5
  • 14
  • @AD7six I've added the full upstream config as a gist, any clue what might be causing the redirection (the path does starts with `/mediafiles`, but I don't think the alias is the culprit). – Olivier Jun 14 '15 at 14:25
  • Why are these in separate containers? – Michael Hampton Jun 14 '15 at 14:46
  • @MichaelHampton Because I have a lot of different services and using nginx as single ssl proxy for all of these (with https://github.com/jwilder/nginx-proxy) – Olivier Jun 15 '15 at 08:25
  • @AD7six the issue comes with static files directly served by Nginx, so there is no application logic that takes place. I've added the full curl output. – Olivier Jun 15 '15 at 08:25
  • @AD7six I've added the proxy config file (did not inlined it as it would harden the legibility), and the full curl output with redirects. – Olivier Jun 15 '15 at 15:24
  • 1
    That's better but please put your config in the question, not linked to off SF. The presence of this header `X-UA-Compatible` suggests the first and 3rd response are from your upstream, which is _possibly_ issued by your node app. I suggest to [use a debug log](http://nginx.org/en/docs/debugging_log.html) and see exactly why the first request is redirecting - it looks like it's redirecting to append a `/` - none of the config shown would do that. Note that you're going from upstream to proxy, to upstream based on the headers. – AD7six Jun 15 '15 at 16:28
  • The only location that seems to be triggered using the `add_header` method is the `/mediafiles` alias. There is no backend involved here are theses requested files are statically served by nginx. – Olivier Jun 15 '15 at 22:08
  • There's still no debug log, and the config is still off site. You have a redirect appending a trailing slash, see for example [this question](http://serverfault.com/questions/562425/nginx-unwanted-location-redirect-with-trailing-slash) it sounds like it's related to your proxy setup. Without the debug log output it's hard to say though: Please edit your question to focus on the problem (unwanted redirect), and not the symptoms (mixed content browser warnings), good luck. – AD7six Jun 16 '15 at 08:10

0 Answers0