Incorrect redirect protocol when behind a reverse proxy

[Jonathan Matthews]

On 25 July 2013 17:14, Glenn Maynard <glenn at zewt.org> wrote:
> On Thu, Jul 25, 2013 at 10:53 AM, Jonathan Matthews
> <contact at jpluscplusm.com> wrote:
>>
>> On my phone's browser, searching for that module name doesn't bring me
>> anything useful I'm afraid. Are you just serving local files off disk?
>
> src/http/modules/ngx_http_static_module.c.  This is where the trailing-slash
> redirects originate.
>>
>> I bet you have redirects configured somewhere, or a backend is generating
>> them ;-)
>>
>> Please post your entire config.
>
> I don't.  It happens with a minimal configuration.
>
> events { }
> http {
>         server {
>                 listen 10000;
>                 root "data";
>         }
> }
>
> mkdir -p data/test/, and then accessing "http://localhost:10000/test"
> redirects to "http://localhost:10000/test/".

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?

HTH,
J
--
Jonathan Matthews
Oxford, London, UK
http://www.jpluscplusm.com/contact.html