Introduction to HTTP Redirects
In this lesson, you’ll learn the answer to the obvious question: what’s an HTTP redirect? This is a response from the webserver that tells your browser that a page has been moved. In addition to telling the browser that the page has been moved, it usually indicates where to. Most browsers automatically load the new location.
The sample code for this course was tested in Django 3 with Python 3.8. The code should be backwards compatible with Django 2.
Here are resources for more information on Django views and URL patterns:
00:00 So, let’s get started! The obvious question: what’s an HTTP redirect? This is a response from the webserver that tells your browser that a page has been moved. In addition to telling the browser that the page has been moved, it usually indicates where to. Most browsers automatically load the new location.
00:18 This means users may not even realize that the redirect has happened. There are several different kinds of redirects, and how the browser caches the response dictates the behavior when the URL is visited again.
00:30 This means you may want to be careful about which kind of redirect you use. So, why would you want to redirect? Let’s start answering that question by looking at how Django itself uses redirects.
00:51 Likewise, once you’ve completed that login, it will redirect you back to the URL you came from. If you’re changing your password, it will redirect you to the Successfully Changed password page, after the password change has been input. And in the Django admin, if you’ve created a new object, it will send you to the object listing, afterwards.
Outside of Django, URL shorteners like bit.ly are, essentially, redirect engines. It’s also an important part of form handling. A common pattern in Django is to use a single view for both presenting the form and accepting its submission. Inside the view, you check whether it is a
GET or a
POST. If it is a
GET, the form is presented to the user.
If it is a
POST, the form is processed for input. If you use this mechanism, you need to be able to send the user to a subsequent page, after the form has been processed successfully. Redirects allow you to do this.
You can see that code here. The
hello_world() view returns an
HttpResponse object using a
content_type='text/plain', meaning just the string
"Hello World\n" gets returned to the web browser—no wrapper HTML. Throughout this course, I’m going to use
content_type='text/plain' to make it easier to see what the results are, rather than having the additional complexity of the wrapped HTML.
curl to print out the headers as well as the body coming back. You can see the response code of
200 coming back from the webserver, six additional headers, as well as the
Hello World body.
In addition to that, you may have come across others, as well.
Unauthorized and causes the browser to pop up an authentication box.
403 tells the user they don’t have permission to see this URL.
404 means the page isn’t found.
There are a series of redirect status codes, starting with
302 was the one that I showed you. In the original specification, it meant
Moved Temporarily. In HTTP 1.1, it was changed to mean
Found. 1.1 also introduced the concept of
This is one of those cases where the standards and the real world don’t really match. Although HTTP 1.1 and on have several different ways of using these redirects, with subtle differences about how to behave in the cases of
POSTs, most programmers still use
302 under its original intent
302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effect of request URI for future requests.
The server SHOULD generate a
Location header field in the response containing a URI reference for the different URI. The user agent MAY use the
Location field value for automatic redirection.” Why is it that specifications always sound like the legalese at the end of a drug commercial?
What this essentially says is the
302 will include a
Location header field containing the value of the new URL. It’s up to the implementation of the browser to decide whether or not to automatically redirect. It also states that in subsequent visits to this original URL, the browser should still hit the original URL as it may no longer be redirected, or it may be redirected somewhere else. This is an important distinction.
06:29 There’s both temporary and permanent redirects. In the case of temporary redirects, the browser should not store this information. Every time the original URL is hit, the browser should attempt to go to that URL. For permanent redirects, the browser’s meant to remember the redirection. Subsequent typing in of the original URL should automatically go to the redirected URL.
Become a Member to join the conversation.