The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. There are several types of redirects:

• Redirects that indicate this resource might be available at a different URI, as provided by the Location header field, as in the status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect), and 308 (Permanent Redirect).
• Redirection that offers a choice among matching resources capable of representing this resource, as in the 300 (Multiple Choices) status code.
• Redirection to a different resource, identified by the Location header field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
• Redirection to a previously stored result, as in the 304 (Not Modified) status code.

Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and 302 (Found) were originally defined as method-preserving ([HTTP/1.0], Section 9.3) to match their implementation at CERN; 303 (See Other) was defined for a redirection that changed its method to GET. However, early user agents split on whether to redirect POST requests as POST (according to then-current specification) or as GET (the safer alternative when redirected to a different site). Prevailing practice eventually converged on changing the method to GET. 307 (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538] were later added to unambiguously indicate method-preserving redirects, and status codes 301 and 302 have been adjusted to allow a POST request to be redirected as GET.

If a Location header field (Section 10.2.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to be done with care for methods not known to be safe, as defined in Section 9.2.1, since the user might not wish to redirect an unsafe request.

When automatically following a redirected request, the user agent SHOULD resend the original request message with the following modifications:

• Replace the target URI with the URI referenced by the redirection response’s Location header field value after resolving it relative to the original request’s target URI.

• Remove header fields that were automatically generated by the implementation, replacing them with updated values as appropriate to the new request. This includes:

  • Connection-specific header fields (see Section 7.6.1),
  • Header fields specific to the client’s proxy configuration, including (but not limited to) Proxy-Authorization,
  • Origin-specific header fields (if any), including (but not limited to) Host,
  • Validating header fields that were added by the implementation’s cache (e.g., If-None-Match, If-Modified-Since), and
  • Resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie.

• Consider removing header fields that were not automatically generated by the implementation (i.e., those present in the request because they were added by the calling context) where there are security implications; this includes but is not limited to Authorization and Cookie.

• Change the request method according to the redirecting status code’s semantics, if applicable.

• If the request method has been changed to GET or HEAD, remove content-specific header fields, including (but not limited to) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.

A client SHOULD detect and intervene in cyclical redirections (i.e., “infinite” redirection loops).

https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx