[PATCH] Added support for client_scheme_in_redirect directive

[Kyle Ibrahim]

Hi Maxim,

I have considered something like `relative_redirects`. It would also be a
good directive to have, but it wouldn't allow 301 redirects from nginx to
always use the same hostname, e.g. www.example.com

e.g.
Currently, I need to set `server_name_in_redirect www.example.com` and MUST
have nginx terminate SSL.
`relative_redirects` wouldn't let me have nginx behind a SSL terminator AND
use `server_name_in_redirect`, because the relative 301s wouldn't force
people to move to www.example.com

I have also considered the option of: `scheme_in_redirect http|https` and
not letting it have a variable. This would simplify the implementation by a
lot.

It wouldn't solve my exact problem, but it would solve the other two
problems I linked in the beginning of my last email.

Thanks for getting back to me (and all your hard work)!
Kyle

P.S. Instead of `client_scheme_in_redirect` I should have just called it
`scheme_in_redirect`



On Wed, Mar 18, 2015 at 9:22 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sun, Mar 15, 2015 at 04:07:11AM -0700, Kyle Ibrahim wrote:
>
> > Currently, there is no way way to control the scheme which will be used
> in
> > nginx-issued redirects. This is a problem when the client is potentially
> > using a different scheme than nginx due to a SSL terminating load
> balancer.
> > As some client requests may have started over http and some over https,
> > we'd like to way to dynamically set the proper client scheme.
> >
> > This is a patch which adds a directive `client_scheme_in_redirect` to
> > complement `server_name_in_redirect` and `port_in_redirect`.
>
> Have you considered doing something like "relative_redirects on|off"
> instead, as previously suggested[1]?
>
> I believe it will resolve the problem as well, and will address
> additional problems too.  It is also expected to require simplier
> and more effective code.
>
> [1] http://mailman.nginx.org/pipermail/nginx-devel/2015-March/006608.html
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150318/295a1ce0/attachment.html>