Incorrect redirect protocol when behind a reverse proxy

[Glenn Maynard]

On Thu, Jul 25, 2013 at 1:41 PM, Jonathan Matthews
<contact at jpluscplusm.com>wrote:

> I've just got to a box and can ACK that. I can make that stop with a
> correctly configured try_files, which I would always choose to have
> set up, myself. That may not be a solution for you however.
>
> Here's a way I've just tested (on 1.4.2) that forces the
> trailing-slash redirects to incorporate a random HTTP header ("foo",
> here) as their scheme:
>
> # include your boilerplate as per previous email
> location / {
>   location ~ "^(.*)[^/]$" {
>     rewrite ^ $http_foo://$http_host$uri/ permanent;
>   }
> }
>
> Or, supposing you have certain URIs which *can* end in
> not-a-trailing-slash: (also tested on 1.4.2)
>
> location / {
>   if (-d $document_root$uri) {
>     rewrite ^ $http_foo://$http_host$uri/ permanent;
>   }
> }
>
>

> I suppose the question is then: what *other* classes of automatic
> redirects do you find yourself hitting, and can you deterministically
> isolate their URIs using either a location{} or if{}, so that you can
> pre-empt the auto redirect in order to incorporate the
> X-forwarded-proto header?
>

Thanks, I'll give these approaches a try.  I don't know where else this
might happen, though.  Hopefully at some point I'll be able to say
something like "override_protocol $http_x_forwarded_proto;" to tell nginx
which protocol it's really receiving a request on, since SSL "offloading"
is fairly common these days (http://aws.amazon.com/elasticloadbalancing/,
etc).

-- 
Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130730/d5a0398e/attachment.html>