A URL redirection (or redirect) is a technique where an HTTP client sends a normal request and in the response server side
indicates that the resource is no longer at the requested location. Server sends this information in the form of a
specific
status code along with 'Location' header. The value of the 'Location' header contains the
new URL of the resource, which client will use to request the resource again (in the second round). The new location
may reside on the same domain or on another one.
There are a number of different status codes used which additionally indicates things like:
whether the redirection is permanent or temporary, what HTTP methods should be used by the
client when requesting the new location (in the second round) and whether it is necessary to cache redirection
information or not.
Followings are the different HTTP status codes relevant to url redirection:
301 (Moved permanently): Indicating that client browser or search engines or proxies should update the
cache with
the new redirection
'Location'. During the second round, the client may alter the HTTP method (e.g. GET to POST or vice versa). The
subsequent requests for the old location will straight go to the new location.
302 (Found): This is temporary redirect. The page developer, for example, may choose to show a different
version/content of the page. No cache is created/updated, unless server explicitly sends relevant Cache-Control or Expires directives. The client may alter HTTP method during the second round. All future requests will still go to the old location and follow the same redirection flow until
the developer is ready to make the original resource available.
303 (See other): Similar to 302 but only allows GET during the second round.
Since GET is
idempotent, 303 is
suitable for scenarios like form POST to
avoid double form submission.
307 (Temporary redirect): Similar to 302 but 307 does not allow to change the HTTP
method during the second round. If client sends PUT (for example) in the first round then it cannot be changed to
something else in the second round.
302 could not be enforced with similar rules because of backward compatibility.
308 (Permanent redirect): Similar to 301 in using aggressive cache of the redirection information, but 308 does not allow to change the HTTP
method during the second round.
301 could not be enforced with the similar rules because of backward compatibility.
Note: Initially 301 and 302 specifications also didn't allow to alter the HTTP methods, but clients still used it against the specifications to address some particular scenarios, that's the reason 303, 307 and 308 status codes were introduced to avoid ambiguity.
