Django Redirects (Summary)
This wraps up this guide on HTTP redirects with Django. Congratulations: you have now touched on every aspect of redirects all the way from the low-level details of the HTTP protocol to the high-level way of dealing with them in Django.
You learned how an HTTP redirect looks under the hood, what the different status codes are, and how permanent and temporary redirects differ. This knowledge is not specific to Django and is valuable for web development in any language.
You can now perform a redirect with Django, either by using the redirect response classes
HttpResponsePermanentRedirect, or with the convenience function
django.shortcuts.redirect(). You saw solutions for a couple of advanced use cases and know how to steer clear of common pitfalls.
Here are resources for more information on Django redirects and HTTP redirects:
- HttpResponseRedirect: Django documentation
redirect() shortcut: Django documentation
RedirectViewclass: Django documentation
- HTTP RFC, 3xx section
- Common Weakness Enumeration article URL Redirection to Untrusted Site
Congratulations, you made it to the end of the course! What’s your #1 takeaway or favorite thing you learned? How are you going to put your newfound skills to use? Leave a comment in the discussion section and let us know.
It doesn’t directly call the view. It returns an HTTP response to the browser. It’s the browser that does the work of coming back. It’s easy to introduce bugs if you forget this fact. For example, let’s say you have a
product_view() that looks up a
Product, and if the product does not exist, does a redirect to
'/'. So far, so good.
Can you see the bug? In the first case,
get_product_or_redirect() returns a
Product. In the second, it returns an
product_view() expects it to be a
Product, and then renders it.
01:29 Another thing to be careful with is redirect loops. A loop can happen if two or more methods redirect back to each other. This is a very simple example. The first view redirects to the second and the second redirects to the first.
product_view() itself looks up a product, which—if it was redirected from
featured_products_views()—will be the single featured product, and if it doesn’t exist, redirects to the
If there’s only one featured product and it’s sold out, the
featured_products_view() will redirect to
product_view(), it won’t be found because it’s not in stock and it will redirect back to
03:11 It stores the original URL, and if you type it in, it will automatically go to the permanent redirect without going to the server. Generally, this is a good thing—until someone changes their mind.
03:22 Let me run you through an example. Let’s say marketing decides to reorganize the site and combine the announcements section with the blog section. To keep your SEO nice and healthy, you permanently redirect the announcements section.
03:36 Then, marketing goes and changes their mind again. Well, you can no longer use your original announcements URL. Anyone who had visited it before will not be able to reach it again unless they empty their cache.
This can particularly bite you in the local development environment. Oftentimes, you run the development server on
localhost. If one of your projects has a
301 in it, your browser will cache this and associate it with the local IP.
If another project then tries to use the same URL, your browser will use the cached redirect. This might result in a
404 because the new project might not have a page with the same name as the redirect.
It might even be worse if it actually had it. This can lead to some head-scratching moments. One way around this is to modify your hosts file with
clientA.example.com associated with
localhost. If you get a redirect from
clientA, it will only apply to
clientA. I like to do this when I’m developing, not just because of this situation, but also because some browsers behave a little oddly when storing things like names and passwords with the local IP. By having an example URL, you’ll always behave closer to the real world.
example.com is actually not a valid domain name, so you can always safely use it. For more information, you can dig into the Django docs. There’s plenty of information on the
HttpResponseRedirect object, the
redirect() shortcut, and the
If specifications are your thing, you can dig into the RFC that talks about the
300 codes, or the Common Weakness Enumeration site has an excellent article on URL redirection to untrusted sites, or the parameterized URL redirect that I showed you earlier—also known as an open redirect.
Become a Member to join the conversation.