How does fetch handle 302s?

Problem Description

fetch sends a request, the request login expires and returns 302, and the browser automatically redirects to the Location login page of the Response Headers. The server corresponding to Location does not accept cross-domain requests, so the page reports an error.

Try processing it in the callback function of fetch, and jump to the Location page once the response status of fetch is 302, but no matter what you do in the callback function of fetch, it cannot be executed.

What is HTTP status code 302?

The HTTP 302 redirect status code indicates that the requested resource was temporarily moved to the URL specified Location The browser will redirect to this URL, but the search engine will not update the link to the resource.

usage scenario:

1. In the OAuth flow, 302 is often used;
2. Sometimes a requested resource cannot be accessed from its standard address, but can be accessed from another location. Temporary redirects can be used in this case.
3. Search engines do not record this new, temporary link. Temporary redirects can also be used to display temporary progress pages when creating, updating, or deleting resources.

Pain point: The browser automatically initiates a request for the redirection address, and js cannot intervene.

Why can't fetch intercept 302?

General request process:

• fetch sends a request;
• The server returns the response with a status code (such as 200);
• The browser receives the response and submits the result to fetch;
• Get the corresponding data from the callback function of fetch;

302 The flow of the temporary redirection request is:

• fetch sends a request;
• The server returns a response (with location) with a 302 status code;
• When the browser receives the response, it automatically jumps to the location from the redirection address of the header information of the 302 response;

For redirection, when the browser detects that there is a Location in the headers, it will jump directly without notifying any request sender (fetch). At this time, the sender will think that the request is still being processed. So at this time, the then and catch of fetch cannot capture information.

How to solve?

1. Configure the redirect of fetch

The options configuration item of fetch is redirect , which is used to configure the available redirect mode.

The values of redirect are:

• follow: default, automatic redirection;
• error: If a redirection occurs, it will automatically terminate and throw an error;
• manual: handle redirection manually;

error

If a redirect occurs it will automatically terminate and throw an error. This error can be caught in the fetch catch callback function: TypeError: Failed to fetch .

fetch only calls catch if the server is wrong, and all others will call the then function, so why does 302 call catch?

It is not the 302 that causes the catch to be called but the response to the redirected request that causes the catch to be called.

manual

Handle redirects manually. Through this method, you can only know that a redirection has occurred, but the content of the response is very limited, and specific information cannot be obtained.

2. The back-end rewrites the status code, and the front-end processes it manually

The current 302 is a rewrite of 404, then if we rewrite 404 into a custom status code, and then the front-end captures this status code and processes it manually. This method requires both front-end and back-end students to deal with it.

Difference between 301 and 302 status codes

301: Permanent redirect. Once the request is sent to a URL and the status code returns 301, the browser will automatically jump to the URL corresponding to the Location in the header. For the next request, send a request to the url corresponding to the location again.

• After that, each request will jump to the url corresponding to the location. Without exception.
• Browsers can cache responses from this url.

302: Temporary redirect. The requested resource is temporarily obtained from a different url. Once the request is sent to a URL and the status code returns 302, the browser will automatically jump to the URL corresponding to the Location in the header. But the next time you request again, send a request to the original url.

• Each request cannot determine whether to send a request to the url of the Location, so it is necessary to send a request to the original url to confirm.
• Browsers MUST NOT cache responses from redirected urls.

Redirect can be used to set cookies

If the browser finds that the response of the current request is to be redirected, it will directly ignore the body of the response and cannot see the body on the network panel in the developer tools. Although the body of the redirected request is ignored by the browser, the headers of the redirected request response can still be used.

For example, when a request server returns 302 and set-cookie is set, the browser can set the cookie under the domain of the current page before initiating the jump. Even if you jump to another domain because of 302, you can still set cookies.

1. User access a domain name
2. The backend returns 302, location is the b domain name, and set-cookie: cookieA
3. The browser plants a cookie under the a domain name: cookieA, and then initiates a request to the b domain name
4. The backend returns 302, location is a domain name, and set-cookie: cookieB
5. The browser plants a cookie under the b domain name: cookieB, and then initiates a request to the a domain name

This is equivalent to achieving such an effect: can plant cookies to different domain names in one request (the redirection is controlled by the backend, and the frontend is transparent, which is equivalent to the effect of only one request).

If you don't need to redirect, you may consider configuring CORS to send a cross-domain request to set cookies, but once CORS involves credentials such as cookies, there will be various restrictions, which are actually difficult to play.

In fact, cross-domain set cookie can also be implemented using the browser's beacon API, of course, there are some limitations

There can be multiple redirects, such as continuous 302, that is, the URL corresponding to the location returns 302 and a new location, and so on until no more jumping locations. To prevent infinite redirects, the number of redirects is capped. The number of redirects of the Chrome browser is 20, and an error of ERR_TOO_MANY_REDIRECT