HTTP redirect HTTPS under load Balancing scenario in ASP.

Last week it was gratifying to find that Microsoft officially finally provided a workaround for ASP. NET Core's force redirection from HTTP to HTTPS with load balancing.

App. Useforwardedheaders (new  forwardedheadersoptions{    = Forwardedheaders.xforwardedproto}); var New rewriteoptions ()    . Addredirecttohttpspermanent (); app. Userewriter (options);

But when it was actually used, Joy became a disappointment-Microsoft's understanding of the problem was not the same as ours, which made it impractical for us and had to continue to use our soil method.

Why is that? Take a look at the decomposition below.

Addredirecttohttpspermanent has long been implemented in Basicmiddleware's Redirecttohttpsrule, and its logic is simple-to determine if the current request is HTTPS, or redirect if not.

if (! context. HttpContext.Request.IsHttps) {    //...}

This straightforward judgment will not only play its rightful role in using load balancing scenarios, but will also have fatal side effects--allowing requests into the redirected dead Loop (err_too_many_redirects). Because regardless of whether the client's request is HTTP or HTTPS, the load balancer is always http between the back-end servers (you can, of course, use HTTPS, but that is full of food and a waste of grain). If load balancing does not provide this information at all, HTTP redirection https is simply not possible in the back-end server's eyes, which always has no HTTPS.

From the point of view of load balancing, in order to solve this problem, usually through an additional dedicated request header to catch this message, its name is "X-forwarded-proto".

From the perspective of ASP., to solve this problem, we need to make up the gap between Request.ishttps and X-forwarded-proto. So Microsoft implemented the app above. Useforwardedheaders (), which is actually done by Forwardedheadersmiddleware--set Scheme according to X-forwarded-proto (Request.ishttps is based on Scheme for judgment).

if (Checkproto && i < forwardedproto.length) {    set1];}

So far, Microsoft has solved this problem perfectly, and Redirecttohttpsrule doesn't have to change 1 lines of code.

But in practical use, we find a big problem that we have to abandon this seemingly perfect solution.

Microsoft's solution to the HTTP to https problem is this: as long as the request is not HTTPS, force jump to HTTPS (this is no problem), regardless of whether the request is from the load-balanced forwarding (this is not intimate).

The problem we're trying to solve is that it forces a jump to HTTPS only if the original request that the Load Balancer forwards is HTTP. For example, in the server native access, such as from other Docker container access, if this also jump, that each server (or Docker container) to deploy HTTPS certificate, much trouble.

One is as long as not HTTPS, jump; one is only forwarding http, just jump. Because of this difference in understanding the problem, we have to abandon the official Microsoft Solution, continue to use our less elegant soil method.

Redirecttoproxiedhttpsrule

 Public classredirecttoproxiedhttpsrule:redirecttohttpsrule{ PublicRedirecttoproxiedhttpsrule () {Base. StatusCode =statuscodes.status301movedpermanently; Base. Sslport =NULL; }     Public Override voidApplyrule (Rewritecontext context) {varKey ="X-forwarded-proto"; varRequest =context.        HttpContext.Request; if(Request. Headers.containskey (key)) {if(Request. Headers[key]. FirstOrDefault () = ="http")            {                Base.            Applyrule (context); }        }    }}

Rewriteoptionsextensions

 Public Static class rewriteoptionsextensions{    publicstatic rewriteoptions Addredirectforwardedhttptohttps ( this rewriteoptions options)    {        options. Rules.add (new  redirecttoproxiedhttpsrule ());         return options;    }}

Use in Startup

var New rewriteoptions ()    . Addredirectforwardedhttptohttps (); app. Userewriter (options);

HTTP redirect HTTPS under load Balancing scenario in ASP.