Technology: HTTP redirects

Customers using the Qrator Labs reverse HTTP proxy can set up some kinds of HTTP redirects on the reverse HTTP proxy side. Using this service, requests requiring redirection will be handled directly by the reverse HTTP proxy without reference to the upstream.

One popular use of HTTP redirects is to force HTTPS for all user requests (see configuration example at the end of the article). In this case, handling HTTP requests on the customer's network can be disabled completely because only HTTPS requests will reach the upstream. This configuration reduces the number of requests sent to the upstream.

Warning

If you plan to enable bot protection for a domain (see Redirection with cookie installation), it is important that redirects from HTTP to HTTPS are performed not by the upstream itself, but by Qrator Labs reverse proxy. Otherwise bot protection will not work correctly.

Principle of operation

In the Qrator Labs dashboard, HTTP redirects with the list of rules can be found in the domain settings. By creating and editing these rules, you can control the behavior of the reverse HTTP proxy. Rules can be added in any order.

When an incoming request arrives, the reverse proxy searches the entire list of rules for the most specific rule that can be applied to the request. This allows you to configure complex combinations of redirect rules. See Examples.

Each rule has conditions under which it is triggered (Request):

  • The protocol that the user used in the original request — HTTP or HTTPS,

  • The host the request is intended for — a specific string or the ANY value corresponding to any host.

If the reverse HTTP proxy finds a rule in the list that matches the current request, it performs the actions described in it (Redirect).

  • The user can be sent an HTTP response code of your choice from the list:

    • 301 Moved Permanently
    • 302 Found
    • 307 Temporary Redirect
    • 308 Permanent Redirect
  • When compiling the URL to which the redirect will be made, the host and path you typed or copied from the original request will be used.

  • GET arguments may be copied from the original request or deleted.

  • Redirection for a given rule can be turned off completely. In this case, requests matching this rule will be forwarded to your network.

Examples

Forced HTTPS enabling

Request Redirect
http://`ANY` 301 https://`$hostname` $path?$args

In this configuration, the reverse HTTP proxy replaces the protocol in all incoming requests from HTTP to HTTPS. It is recommended to use the 301 Moved Permanently code so that the user's browser can cache the response on its side and not perform HTTP requests next time.

Creating exceptions to a rule

Request Redirect
http://`ANY` 301 https://`$hostname` $path?$args
http://old.example.com Disabled

This example is similar to example with forced redirection to HTTPS, but it adds a second rule which says that for requests to old.example.com, no redirection should be performed. The reverse HTTP proxy prefers a more exact match when matching the request with rules, so the first rule stops being applied for requests to old.example.com.

This configuration is useful if you have one or more sites served by your upstream that does not support secure HTTPS, but you want to force this protocol on all other sites.

Redirecting to a new host

Request Redirect
https://`ANY` 301 https://www.example.com/
https://www.example.com Disabled

Suppose your content is hosted on wiki.example.com, app.example.com and other *.example.com subdomains served by the same upstream, but you need to redirect all visitors from those hosts to the main page on a new main host www.example.com after a structural change.

In this situation, you can create two rules as described above. The first rule applies to all HTTPS requests, but the second rule creates an exception to the first rule for the primary host, thus preventing cyclic redirections.

expand_less