[PATCH] Added support for client_scheme_in_redirect directive
kibrahim at getpantheon.com
Wed Mar 18 18:06:46 UTC 2015
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
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
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)!
P.S. Instead of `client_scheme_in_redirect` I should have just called it
On Wed, Mar 18, 2015 at 9:22 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 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
> > nginx-issued redirects. This is a problem when the client is potentially
> > using a different scheme than nginx due to a SSL terminating load
> > 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?
> 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.
>  http://mailman.nginx.org/pipermail/nginx-devel/2015-March/006608.html
> Maxim Dounin
> nginx-devel mailing list
> nginx-devel at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel