How to Make Django Redirect WWW to Your Bare Domain

Where to Redirect?

You can configure such a redirect at one of several layers in your stack.

Adding a Middleware

We then want to check inside our Django code for the “www” domain and redirect such requests to the bare domain.

Because we want to run this check on every request, we’ll want to do it in a custom middleware component. Middleware acts like “onion skin” layers around our normal application. It allows us to see every request as it comes in, and every response as it goes out.

Django allows us to write middleware as either a function or a class. I find the class style slightly easier to follow, so let’s use that here.

Add this middleware class to one of your Django applications in a file called middleware.py:

# myapp/middleware.py
from django.http import HttpResponsePermanentRedirect


class WwwRedirectMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        host = request.get_host().partition(":")[0]
        if host == "www.example.com":
            return HttpResponsePermanentRedirect("https://example.com" + request.path)
        else:
            return self.get_response(request)

Notes:

• The filename is a convention. Django doesn’t automatically discover middleware, but it’s best for us to store it in a logical location.
• The __init__ method runs when Django starts up. We are passed a get_response function that represents calling the next middleware, or if we’re the last middleware, the view.
• The __call__ method is called for each request. We need to return a response from it. This can come either from get_response, or we can generate it ourself to “shortcut” calling the next middleware/view.
• In our __call__ body, we get the requested host with the request.get_host() method. This will check the standard HTTP “Host” header, but also works if we configure Django to recognize different headers set by intermediate proxies.
• We take the full host and split it up using the str.partition method. This allows us to strip any port clause off the host name, for example turn localhost:8000 into just localhost.
• If the host name matches our “www” domain, we return a permanent redirect response, adding the full path to the example.com domain. Otherwise, we return the result of the get_response function, allowing the remaining middleware and view to run as normal.

To deploy this, we need to ensure both domains are in our ALLOWED_HOSTS setting:

# settings file
ALLOWED_HOSTS = [
    # ...
    "example.com",
    "www.example.com",
    # ...
]

We’ll also need to add our middleware to the MIDDLEWARE setting. It should be as close to the top as possible, but after at least SecurityMiddleware which sets some security headers on all responses:

# settings file
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "myapp.middleware.WwwRedirectMiddleware",
    ...,
]

Adding Tests

Let’s add some unit tests to check our middleware responds correctly in the main situations we care about.

We might be tempted to test our middleware by making requests to a view using the test client and seeing when we get redirected. These would work, but they wouldn’t be the simplest or fastest. They’d still depend on running all the other middleware and the view.

We can instead write “pure” unit tests by using Django’s RequestFactory. We use this to generate standalone request objects, and see how our middleware responds to them in isolation.

Let’s look at these tests:

# myapp/tests/test_middleware.py
from http import HTTPStatus

from django.test import RequestFactory, SimpleTestCase

from core.middleware import WwwRedirectMiddleware


class WwwRedirectMiddlewareTests(SimpleTestCase):
    def setUp(self):
        self.request_factory = RequestFactory()
        self.dummy_response = object()
        self.middleware = WwwRedirectMiddleware(lambda request: self.dummy_response)

    def test_www_redirect(self):
        request = self.request_factory.get("/some-path/", HTTP_HOST="www.example.com")

        response = self.middleware(request)

        self.assertEqual(response.status_code, HTTPStatus.MOVED_PERMANENTLY)
        self.assertEqual(response["Location"], "https://example.com/some-path/")

    def test_www_redirect_different_port(self):
        request = self.request_factory.get(
            "/some-path/", HTTP_HOST="www.example.com:8080"
        )

        response = self.middleware(request)

        self.assertEqual(response.status_code, HTTPStatus.MOVED_PERMANENTLY)
        self.assertEqual(response["Location"], "https://example.com/some-path/")

    def test_non_redirect(self):
        request = self.request_factory.get("/", HTTP_HOST="example.com")

        response = self.middleware(request)

        self.assertIs(response, self.dummy_response)

    def test_non_redirect_different_port(self):
        request = self.request_factory.get("/", HTTP_HOST="example.com:8080")

        response = self.middleware(request)

        self.assertIs(response, self.dummy_response)

Notes:

• We subclass Django’s SimpleTestCase, rather than TestCase, because we don’t need the database. (I previously covered how using the right test case classes lead to a 3x speed up for a client’s project.)

• In setUp() we construct a few things and store them on self for use in the test methods. We create a RequestFactory to allow us to create requests.

  We create a sentinel object() to act as a “dummy response.” We use this in the tests to see if the middleware returns the exact value from the get_response function, without needing to construct a full response object. (If you’ve not seen them before, I recommend Trey Hunner’s article on sentinels.)

  Finally we create an instance of our middleware, passing it a lambda that acts as the get_response function.

• Each test method follows the Arrange Act Assert pattern.

  We “arrange” by constructing a certain request to pass to our middleware.

  We “act” by calling the middleware with that request and storing the returned response.

  We then “assert” on that returned response. In the test methods we expect it to redirect, we check for the HTTPStatus.MOVED_PERMANENTLY status code and the location we’d be redirected to. In the others, we check that we got the dummy response object back, indicating the middleware would call the lower layer.

These tests run very fast. This is because they avoid executing other middleware, views, or any database queries:

$ python manage.py test myapp.tests.test_middleware
System check identified no issues (0 silenced).
....
----------------------------------------------------------------------
Ran 4 tests in 0.001s

OK

These unit tests should give us confidence to deploy the change to production. If you make any changes to the middleware, don’t forget to update and rerun the tests.

Deploying

With all the setup and testing, you should be pretty confident that the change will work. Don’t forget that once this is deployed, both domains’ DNS records need to point to your application. You should also make sure your HTTPS certificate includes both domains.

Fin

I hope this helps you set up your domain redirect. Django’s full middleware topic guide is definitely worth a read to learn more about middleware.

—Adam