Often search engine bots store cached information about website pages, which leads the user to a blank page or the user goes over the insecure HTTP protocol instead of the encrypted HTTPS.
For these cases there is redirection or redirect from one page of the site to other domains/pages, it can be implemented at different stages. In this material we will consider the main ways and cases!
Redirect from HTTP to HTTPS
Connecting via HTTP protocol is not considered a benchmark for secure communication for a long time, so many services already use the upgrade to HTTPS, an encrypted connection on top of the classic one.
There are rules in Apache and Nginx that allow you to manage virtual hosts and the server as a whole. To configure such an upgrade of a URL scheme from HTTP to HTTPS, you need to go to the configuration files of the virtual host and configure the traffic handling rules:
By default, the configuration file is called default, if it is different in your case, replace it. Add the configuration:
listen 80;
server_name example.com;
return 301 https://$host;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/keys/subkeys/certificate.crt;
ssl_certificate_key /etc/nginx/keys/subkeys/private.key;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
server_name example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
}
Virtual hosts are divided into logical server blocks, where internally contain traffic handling policies. Thus, if the first block receives a network packet on port 80, which is classically HTTP, it will return a return 301 directive requiring the browser to visit the site, which will already be with the HTTPS scheme.
Note that in addition to the classic settings, a Strict-Transport-Security header is added, which gives the users' browsers a label that it is necessary to force an HTTPS connection instead of a non-secure one. This feature allows to mitigate the HTTP downgrade attack, which allows to downgrade a client connection to an insecure protocol, without authentication and integrity checks, technically by the same return 301!
Let's check the performance of our service and the previously configured redirect:
However, if we don't want to send redirect codes to the user, there are great alternatives to internal redirects.
Internal Redirect
To handle traffic in nginx there is a whole array of directives that allows you to implement another redirect. In this case, the web server will redirect the request internally and process it internally, giving a correct response. The syntax of the directive is as follows:
listen 80;
server_name example.com;
location / {
internal_redirect @check_antivirus;
}
location @check_antivirus {
internal;
root /var/www/html
}
location /url {
internal_redirect /newurl;
}
location /newurl {
internal;
root /var/www/html
}
}
In this example, when traffic comes in on the / and /url paths, an internal redirect to the other path will occur with the rest of the packet intact. For example, your request was on the path /url/new/id?customer=675 and it will become /newurl/new/new/id?customer=675. The examples indicate that you can use a named @location or path. After making the changes, don't forget to verify the configuration with the command:
The redirect logic itself can be stored not only on the server, but also in passed JS/HTML forms!
Redirection via HTML/JS
To implement the redirection logic in the browser you need to use directives of the following form:
<meta http-equiv='refresh' content='0;URL=http://site.io'/>
<head>
In fact, there is a handler in the browser that allows you to read the strings in the HTML and according to the directives perform the action, in this case, the redirect directive is embedded. Where http-equiv=‘refresh’ indicates the need to reload the page, content='0;URL=http://site.io' after 0 seconds at a URL of the form http://site.io.
For JS there is a set of functions that can allow the client to connect to another resource independently, in this case the functionality is more extensive:
The line represents a direct redirection without conditions, where a new connection is opened instead of an existing one. And in the second case below, a logical condition must be met, which will also redirect the user.
The possibilities on the web to control the logic of traffic processing are as extensive as possible, at every stage, from the browser and its HTML/JS handlers to the web server with directives! If you don't have sufficient resources than you can perform actions on powerful cloud servers. Serverspace provides isolated VPS / VDS servers for common and virtualize usage.
Conclusion
Configuring HTTPS redirects is an essential step to ensure secure communication between your website and users. By implementing redirection at the server level using Apache or Nginx, you can enforce HTTPS connections and protect against HTTP downgrade attacks. Additionally, internal redirects and client-side redirections via HTML or JavaScript provide flexible methods to manage traffic and maintain seamless user experience. Properly setting up HTTPS redirects not only enhances security but also improves SEO rankings and builds trust with your visitors.
FAQ
- 1. Why should I redirect HTTP traffic to HTTPS?
Redirecting HTTP to HTTPS ensures that all data exchanged between your website and users is encrypted. This protects sensitive information from interception, improves SEO rankings, and builds user trust. - 2. What is the difference between a 301 redirect and an internal redirect in Nginx?
A 301 redirect sends a permanent redirection response to the client, instructing the browser to load the new HTTPS URL. An internal redirect, on the other hand, redirects the request internally on the server without informing the client, keeping the URL unchanged. - 3. Can I implement HTTPS redirects using HTML or JavaScript?
Yes, you can use meta tags in HTML or JavaScript functions to redirect users to HTTPS. However, server-level redirects are more secure and recommended because they protect against HTTP downgrade attacks and enforce encryption for all visitors. - 4. What is the role of the Strict-Transport-Security (HSTS) header?
The HSTS header tells browsers to always use HTTPS for your site, even if a user types HTTP. This helps prevent protocol downgrade attacks and ensures that all future connections remain encrypted. - 5. Do I need a separate redirect for subdomains?
Yes, if your subdomains are hosted separately, you should configure HTTPS redirects for each one or use the includeSubDomains directive in the HSTS header to enforce HTTPS across all subdomains. - 6. How can I test if my HTTPS redirect is working correctly?
You can test your redirect by accessing your site using http:// in a browser and verifying that it automatically changes to https://. Additionally, use commands like curl -I http://yourdomain.com to check the HTTP response codes and confirm a 301 redirect.