What is mod_rewrite?

mod_rewrite is a powerful and flexible URL rewriting module used in the Apache HTTP Server. It allows web administrators and developers to rewrite URLs in a dynamic and configurable way, either for SEO (Search Engine Optimization) purposes, to improve user experience, or to provide enhanced security. The module works by intercepting HTTP requests and modifying the URL before passing the request to the appropriate handler.

In essence, mod_rewrite provides a means of changing the way URLs are processed, allowing developers to map different URLs to different files on the server. For example, it can help to rewrite complex URLs into simpler, more readable formats, or it can be used to perform redirects from old URLs to new ones.

A typical use case of mod_rewrite is when a website structure changes, and old URLs need to be redirected to new ones to avoid broken links or 404 errors. It can also be used to implement friendly URLs that are more readable and more likely to rank well in search engines.

What are the Major Use Cases of mod_rewrite?

1. URL Redirection:
   • One of the most common use cases of mod_rewrite is redirecting old URLs to new ones. When website structures change, or content is moved to a different location, mod_rewrite can be used to ensure that users are automatically redirected to the correct page without encountering a 404 error.
   • For example, if a page URL changes from /old-page to /new-page, a simple redirect rule can be applied: RewriteEngine On RewriteRule ^old-page$ /new-page [R=301,L] This rule ensures that anyone visiting /old-page will be redirected to /new-page with a 301 (permanent) redirect.
2. SEO-Friendly URLs:
   • SEO-friendly URLs are easier for both search engines and users to understand. mod_rewrite is often used to convert long or complex URLs into shorter, more meaningful ones that include relevant keywords.
   • For example, a dynamic URL like example.com/products.php?id=123 can be rewritten to example.com/products/123, making it cleaner and more user-friendly: RewriteEngine On RewriteRule ^products/([0-9]+)$ /products.php?id=$1 [L]
3. Security Measures:
   • mod_rewrite can also be used to enhance security by blocking access to certain parts of a website or server. For example, you can prevent access to sensitive files by checking for certain conditions, such as whether the request is coming from a specific IP address or whether the user is authenticated.
   • A common security measure is to block access to hidden files or directories (those starting with a dot, like .htaccess or .git): RewriteEngine On RewriteRule ^\.git - [F]
4. Redirect HTTP to HTTPS:
   • Another popular use case for mod_rewrite is ensuring that all traffic to a website is served over HTTPS. This is important for security, as HTTPS encrypts the communication between the user’s browser and the server.
   • A common rewrite rule for redirecting all HTTP traffic to HTTPS is: RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
5. Prevent Hotlinking:
   • mod_rewrite can be used to prevent hotlinking, which occurs when other websites link directly to your images or media files, using up your bandwidth.
   • To prevent hotlinking, you can create a rewrite rule that only allows images to be served from your domain: RewriteEngine On RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain\.com [NC] RewriteRule \.(jpg|jpeg|png|gif)$ - [F]

How mod_rewrite Works Along with Architecture?

mod_rewrite works within the Apache HTTP Server as a module that hooks into the request handling process. When a request is received by Apache, mod_rewrite intercepts the request and evaluates any applicable rules defined in .htaccess files or in the main server configuration.

Here’s a breakdown of how mod_rewrite fits into the architecture of Apache:

1. Rewrite Engine Activation:
   • The RewriteEngine On directive activates the rewrite engine. Without this directive, no rules will be processed.
   • The rewrite engine runs before Apache serves the content, giving it the opportunity to modify the URL as needed.
2. Rewrite Conditions (RewriteCond):
   • Rewrite conditions are used to define prerequisites that must be met before a RewriteRule is applied. Conditions can be based on various server variables, including the HTTP request, headers, or environment variables.
   • For example, you can use RewriteCond to check whether the request is made over HTTP or HTTPS and apply a rule accordingly: RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
3. Rewrite Rules (RewriteRule):
   • RewriteRule is the directive that defines how a URL is rewritten. A typical rule consists of a pattern (which can include regular expressions) and a substitution (the new URL or path).
   • The [L] flag indicates that no further rules should be processed if this rule matches, while the [R] flag is used for redirection. You can also use [NC] for case-insensitive matching.
4. Processing Flow:
   • When a request is made, the server first checks the URL against all defined RewriteCond conditions. If any of the conditions are met, the server then applies the corresponding RewriteRule.
   • If the rule results in a redirection, the server sends the appropriate HTTP status code (e.g., 301 for permanent redirects). If a rule modifies the URL without redirecting, the server proceeds with the request as if the new URL was originally requested.

What are the Basic Workflows of mod_rewrite?

The basic workflow of mod_rewrite involves several steps in the request handling process. Here’s a simplified flow of how mod_rewrite operates:

1. Request Received:
   • Apache receives an HTTP request for a specific URL.
2. Rewrite Engine Activation:
   • If RewriteEngine On is set, mod_rewrite is activated and begins processing the request.
3. Check Rewrite Conditions:
   • The server evaluates the conditions defined in RewriteCond. These conditions can be based on the HTTP request, the user’s IP address, or other criteria.
   • If no conditions are specified, the rule is applied immediately.
4. Apply Rewrite Rules:
   • The server processes the RewriteRule directives and checks if the request URL matches any defined patterns (using regular expressions).
   • If a match is found, the rule is applied, either rewriting the URL or redirecting the request to a new URL.
5. Redirect or Internal Rewriting:
   • If a rule causes a redirect (using the [R] flag), Apache sends the appropriate HTTP status code (e.g., 301 for permanent redirects).
   • If the rule performs internal URL rewriting (using the [L] flag), Apache processes the request as though the rewritten URL was the original request.
6. Final Processing:
   • Once all applicable rules are processed, the request continues to be handled by Apache, which serves the requested content or invokes the appropriate application or handler.

Step-by-Step Getting Started Guide for mod_rewrite

Here’s a step-by-step guide to get started with mod_rewrite in Apache.

Step 1: Enable mod_rewrite Module

The mod_rewrite module is usually enabled by default in Apache. However, if it’s not enabled, you can enable it by running the following command (on Ubuntu/Debian systems):

sudo a2enmod rewrite
sudo systemctl restart apache2

Step 2: Enable .htaccess File Usage

If you want to use .htaccess files for URL rewriting, you need to ensure that Apache is configured to allow overrides. Open your Apache configuration file (httpd.conf or apache2.conf), and ensure the following is set:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Restart Apache:

sudo systemctl restart apache2

Step 3: Create or Edit .htaccess File

Create or edit the .htaccess file in the root directory of your website. Here’s an example of how to enable mod_rewrite and create basic URL rewriting rules:

RewriteEngine On
RewriteRule ^about$ /about-us [R=301,L]

This rule redirects /about to /about-us with a 301 permanent redirect.

Step 4: Test Your Rewrite Rules

Once you’ve added or modified rules in your .htaccess file, test the website to ensure that the rewriting works as expected. Try visiting the old URLs or the rewritten URLs to see if the redirects or rewrites are functioning properly.

Step 5: Troubleshooting

If the rewrite rules aren’t working, check the following:

• Ensure that the .htaccess file is located in the correct directory (typically the root of your website).
• Verify that mod_rewrite is enabled.
• Check Apache’s error logs for any issues related to URL rewriting.

Before the invention of CI/CD (Continuous Integration and Continuous Deployment & Delivery), software was generally developed by writing the code using a computer whenever it was time to move the software to production. The RedHat website defines CI/CD to be “a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.”

In other words, CI/CD is a process that replaces the traditional/manual ways of building and deploying software applications. The CI/CD process is automated and executed once a trigger is met. The trigger is mostly attached to a new git commit to ensure that the latest version of a repository’s code is built and deployed with minimal effort to the developer

Handling Continuous Integration & Delivery With GitHub Actions
To further understand how continuous integration and delivery work, we will focus on deploying a URL shortener application API server on Heroku using Github Actions. The application is a NodeJS server and supports:

Shortening a URL by making a POST request to /shorten with a request body containing the code to identify the URL and a url as the URL to redirect to. If no code is sent, it simply generates a random code and returns it as part of the response.
Visiting a shortened link by making a GET request to /:code; the code is the unique code identifier used when shortening the URL.
Monitoring analysis by making a GET request to /analysis/:code; the :code is the unique code identifier used when shortening the URL.
We don’t necessarily have to create a new application since we can deploy a private repository that our Github account has access to, but we can also deploy a public repository. The workflow will check out the code from the application repository, add Heroku git remote URL, and finally deploy the application to Heroku.

ABOUT GITHUB ACTIONS
Github Actions is one of the services offered by Github Inc. According to the release note:

“GitHub Actions is an API for cause and effect on GitHub: orchestrate any workflow, based on any event, while GitHub manages the execution, provides rich feedback, and secures every step along the way. With GitHub Actions, workflows and steps are just code in a repository, so you can create, share, reuse, and fork your software development practices.”
Github Actions is one of the many options that could be used to implement continuous software deployment and delivery(CI/CD) by ensuring that a new version of a software is shipped to the production or testing area as soon as possible.