Http Response Code After Redirect

What is correct HTTP status code when redirecting to a login page?

I'd say 303 see other 302 Found:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

fits a login page most closely in my opinion. I initially considered 303 see other which would work just as well. After some thought, I'd say 302 Found is more fitting because the requested resource was found, there just is another page to go through before it can be accessed. The response doesn't get cached by default which is fine as well.

Which is the proper HTTP response code for redirection?

To save me a lot of typing - read this and this.

NB - not all the 3xx codes do redirection. But the semantics of 301, 302, 303 and 307 are similar.

Return custom http code after redirection in flask

I want to return HTTP code 201 for a record created and then redirect to the intended route.

That's not something you can do with HTTP. A redirect is itself a specific HTTP 30x status code:

In HTTP, redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.

Either you return a 201 status code or you return one of the HTTP redirection status codes. You can't do both.

The flask.redirect() function generates a valid 30x response (with the required Location header), and the documentation for the function states what redirect status codes are supported:

Supported codes are 301, 302, 303, 305, 307, and 308. 300 is not supported because it’s not a real redirect and 304 because it’s the answer for a request with a request with defined If-Modified-Since headers.

The function doesn't enforce this, however; the status code is not validated.

You need to distinguish between a browser and other clients here. A 201 Created response is something you typically return from a REST API to a client that expects simple JSON or XML interactions at a programmable level. Redirects, on the other hand, are more typically used in a frontend, in the presentation layer.

If you are coding a HTML-based front-end, just return a redirect. Humans don't read response codes, they read rendered HTML pages. They don't care and don't need to know the exact HTTP codes used to make the browser do the right thing. Given that your route also includes a form, you are almost certainly building a site for humans and not for programmatic clients.

If you are building a REST API, then return a 201 response, and document that the API client will have to make a new request based on the Location header you included, or on something in the body of the response. A HTML browser will not follow the Location header on 201 responses however.

I then would not use the redirect() function for this, even if it does allow you to use 201 as the status code, because it always produces a (simple) HTML body containing the text you see in your browser about an automatic redirect.

Response.Redirect HTTP status code

Responses with status 301 are supposed to be cacheable, and I don't think you want that behavior for most ASP/ASP.NET redirects.

ASP.NET 4.0 is has the RedirectPermanent method for that if needed.

What HTTP response status code to use for unrelated redirects of random chance?

The official source for HTTP response status codes is RFC7231, not Wikipedia.
You should peruse RFC7231 Section 6.4 for the explanation of 3XX status codes.

The "redirecting visitors by random chance" thing is irrelevant to the actual redirection,
therefore the status code that fits your requirement is 303,
which is explained in Section 6.4.4 as follows (emphasis mine):

The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an
indirect response to the original request. A user agent can perform
a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the
effective request URI.

303 fits your requirement for three reasons:

1. "to a different resource": the resource your visitors are redirected to is not the same resource they originally requested.
2. "perform a retrieval request": the eventual resource is acquired using a GET or HEAD request.
3. "not considered equivalent": the original request URI must not be replaced by the new URI because it is not equivalent, in other words, it is temporary.

Why not 302?
Because of this part of the explanation in Section 6.4.3 (emphasis mine):

For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request.

In other words, the user agent can use either the same request method or a different request method.
The flexibility that the specification allows for 302 doesn't fit your requirement.

---

Related Topics