Recently a good study of the HTTP 3XX status code, found that it involves a lot of knowledge points, many in our daily development process will also use, so I want to talk with you through this article about their meaning and application scenarios.

The 3XX status code is about redirection. The common status codes are 301,302,303,304,307 and 308. These status codes can be roughly divided into three categories, including:

  • Permanent redirection: 301,308
  • Temporary redirection: 302,303, 307
  • Other redirects: 304

This article focuses on the status codes associated with permanent and temporary redirects, but other redirects are not covered here.

PS: the 3XX response mentioned in the body only contains the HTTP status code for permanent and temporary redirects, excluding other redirects.

start

We need to understand both what the various redirect status codes sent by the server mean and what the browser does when it receives them. Therefore, this article will cover both server and browser.

The server

Permanent redirection

Permanent redirection means that the resource address requested by the user has been deprecated and now needs to be accessed using a new address, which is notified to the user via the Location field of the response Header.

For example, there is a restaurant we often go to in Hutongkou, but the restaurant is moved to another place due to the reconstruction of the old city. One day when we went to this restaurant for dinner, we found a notice posted on the door: the restaurant has been moved to XXX, with the details of the new address. Which means that if I ever want to eat at this place again, I’ll have to go to the new address.

301 Moved Permanently

Indicates that the requested resource has been moved to the URI specified in the Location header and is fixed and will not change. When a Request is made with a new URL, it remains the same for GET requests, but for POST requests, most browsers do not comply with the standard that browsers should not modify the HTTP Method and Request Body when they receive the response. Redirects a POST request to a GET request.

We put Chrome to the test and here’s what we found:

As you can see from the screenshot above, after receiving the 302 response, the browser gets the new address /pets from Location and initiates a new request. However, this new Request uses the GET method instead of our original POST method, and the Request Body is missing.

Application Scenarios:

For example, the URL of an application is changed after the site-wide reconstruction. In this case, you can redirect the old URL to the new URL.

308 Permanent Redirect

As with 301, the only difference is that the browser does not change the HTTP Method and Request Body of the Request.

We went on to test Chrome, and here’s what we found:

As you can see, the Request Method and Request Body remain unchanged after using 308.

Temporary redirection

For some reason, the resource address requested by the user is temporarily unavailable, but some other address is accessible, so the user is notified of this temporary address through the Location field of the response Header.

For example, when we go to a restaurant for dinner, we find that the owner has posted a notice on the door saying, “Family emergency, please go to another nearby restaurant for dinner, with the detailed address of the restaurant.” This way, we can temporarily eat at this branch, and then when the owner comes back, we can continue eating at the same place.

302 Found

After receiving the 302 response, the browser makes a new Request, although the standard says that browsers should not modify the HTTP Method and Request Body when receiving the response, but most browsers do not comply with this standard. Most browsers will treat a 302 request as a 303 request, meaning that 302 and 303 are almost identical.

Application scenarios:

Image resources often in static resources like S3 servers, out of respect for privacy and security, we sometimes cannot be accessed directly by static resource server URL to the image, but need the back-end through authentication credentials to S3 issued a temporary address (this address with a failure, the next need to issued). Then we can access the real image resource through this temporary address.

For this scenario, 302/303 is very useful. For example, the front end can use a fixed URL to access image resources (<img SRC =”/image/foo.jpg”). This URL is provided by the back end, and after generating the temporary address, the back end can directly redirect to the new address through 302/303. The browser then makes another request to retrieve the image resource to which the new address points.

303 See Other

After the browser receives the 303 response, all methods are changed to GET except the GET method, and the Request Body is lost. Typically used to redirect a POST method to a GET method.

Application scenarios:

Suppose we have a very primitive form that is submitted by setting action and Method on THE HTML. After the form is submitted, the browser automatically redirects to the address of the action and sends a request to the server using the method specified. After receiving a 303 response from the server, the browser needs to go back to the original page.

<form action="http://example.com/api/form" method="POST">
    <input type="text" name="name" placeholder="name">
    <input type="email" name="email" placeholder="email">
    <input type="submit" value="Submit">
</form>
Copy the code

A problem arises here, assuming that the URL of our page is example.com, we can only request the page using the GET method. The URL used to submit the form is example.com/api/form, and we can only call this interface through the POST method. After submitting the form using the POST method, if we want to return to the original page, we can only use the GET method to initiate the request, so we need to use the 303 status code to change the original POST method to GET.

307 Temporary Redirect

307 is the same as 303, except that the browser does not change the HTTP Method and Request Body of the Request. Useful for non-GET requests such as POST/PUT.

Application Scenarios:

When uploading a file, we usually invoke one of the apis provided by the back end (/upload), but because uploading takes up a lot of server resources and bandwidth, this API typically does not handle the actual upload, but rather through another dedicated upload service. This means that we need to call the API twice to complete the upload function, one is to call the back-end interface to get the real upload address, and the other is to Request the upload address with the Request Body to complete the real upload.

If you keep the parameters and methods of the two apis the same, the front end only needs to make a Request once, the back end generates the upload address, redirects to that address via 307, and the browser requests the new address using the previous Request Body and HTTP Method. That completes the upload.

Note that using 302 will cause the upload to fail because 302 will change PUT to GET and the Request Body will be lost.

Other common redirection scenarios

Domain names

  1. Expand your site’s reach. A visit to www.google.com, for example, is redirected to google.com
  2. Migrate to another domain name.
  3. Force HTTPS to be used. For example, visiting Baidu.com will be redirected to Baidu.com

Keep links valid

When you refactor your site, you may change the URL of the resource. But we don’t want to invalidate old links because these links not only bring you valuable users, but also help optimize SEO, so you need to set up redirection mapping from old links to new links.

The browser

We’ve seen the various HTTP status codes for redirects, so what do browsers do when they receive them? When the browser receives a 3XX response, does it change the URL of the address bar to the URL specified in the Location field of the response Header and jump to the new URL? Please read on.

After receiving a response from 3XX, does the browser change the address bar and jump to other browsers?

Whether the browser changes the address bar and jumps depends on whether the requested URL causes the document to load/reload. By document load/reload, we mean both the loading of a document when we visit a URL through the browser address bar and refresh the page, and the loading of a document with a new URL through window.location. Only in these cases, if the URL we requested returns a 3XX response, will the browser read the Location field in the response Header, change the browser’s address bar to the URL specified by that field, and jump to that URL.

Document loading/reloading typically produces a Document request like this:

The React Router does not reload the document (because it uses the History API).

However, if you get a 3XX response from a fetch/XMLHttpRequest call, the browser will not change the URL of the current address bar and jump. Imagine that when we visit an image, we often get a lot of 302 responses. If the browser tries to jump to the URL, the whole browser will crash.

Window.location + 3XX response

Window. location allows the document to be loaded with a new URL. By default, the new URL is pushed into the browser history routing stack. If you want to use replace, The window.location.replace() method can be called:

window.location = "http://www.mozilla.org";

function reloadPageWithHash() {
  var initialPage = window.location.pathname;
  window.location.replace('http://example.com/#' + initialPage);
}
Copy the code

Application Scenarios:

When using OAuth2 authentication (such as wechat login), you can redirect to your server’s authorization address via window.location (if multiple platforms are supported, it can be processed by the back end), then the server will generate a third-party authorization address, and inform the browser through 302 response. After receiving the response, the browser will jump to the URL of this tripartite authorization point (wechat login page). After authorization is completed, the tripartite authorization page will be redirected back to our own page through window.location.

With window.location and 302 response, we can quickly direct the user to the tripartite authorization point without loading any JS, which is very fast and convenient.

Reference: developer.mozilla.org/zh-CN/docs/…