Examples of 302 vs 303

Solution 1:

The description on the page to which you linked seem to be fairly descriptive of their intended purpose:

A 302 redirect indicates that the redirect is temporary -- clients should check back at the original URL in future requests.

A 303 redirect is meant to redirect a POST request to a GET resource (otherwise, the client assumes that the request method for the new location is the same as for the original resource).

If you're redirecting a client as part of your web application but expect them to always start at the web application (for example, a URL shortener), a 302 redirect seems to make sense. A 303 redirect is for use when you are receiving POST data from a client (e.g., a form submission) and you want to redirect them to a new web page to be retrieved using GET instead of POST (e.g., a standard page request).

But see this note from the status code definitions -- most clients will do the same thing for either a 302 or 303:

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

Solution 2:

There are five different redirect types. Originally there were only two (301 and 302) but most clients implemented them incorrectly so three more were added to clarify the difference between the two different possible behaviours.

The RFC you linked to states this in the section on 302 redirects:

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

The original redirects

• A 301 redirect is a permanent redirect. It is cacheable and any bookmarks for this URL should be updated to point to the new URL.
• A 302 redirect is a temporary redirect. It is not cacheable by default and should be re-requested every time (but you can override this with caching headers).

For both of the above, the follow-up request should use the same method (POST, GET, CONNECT, PUT, DELETE, etc.) as the original request and for anything other than GET and HEAD requests, the client should prompt the user before making the request.

Unfortunately this is the part that clients sometimes get wrong and most of them change the method for the follow-up request to GET, regardless of the original method. Because of this, three more redirect codes were created:

The newer redirects

• A 303 redirect is the same as a 302 (ie. temporary) except that the follow-up request is now explicitly changed to a GET request and no confirmation is required.
• A 307 redirect is the same as a 302 (ie. temporary) except that the follow-up request is now explicitly the same as the original request and confirmation must be acquired from the user for request methods other than GET and HEAD.
• A 308 redirect is the same as a 301 (ie. permanent) except the request method and the body will not be altered.

Modern clients should not have any issues with these newer redirects.