What http status code is supposed to be used to tell the client the session has timed out?

Question

In a webpage, it uses YUI connection manager/datasource to send AJAX requests to the server, if the session (which contains the info on whether the user has been authenticated) has already timed out, those ajax responses that can only be viewed by authenticated users should return an http status code, telling the client that the session has already timed out, then the client either simply redirects him to the login page or asks him if he wants to extend the session.

My question is that, in this situation, what http status code is the most appropriate to tell the client the session has timed out?

List of HTTP status codes from wiki

Solution 1

Best I can suggest is a HTTP 401 status code with a WWW-Authenticate header.

The problem with 403 requests is the the RFC 2616 states "Authorization will not help and the request SHOULD NOT be repeated." (i.e. doesn't matter if you are authenticated or not, you are not going to get access to that resource, ever).

The problem with 401 requests is it states they "MUST include a WWW-Authenticate header field". As someone has noted it doesn't appear to be in violation of the spec to use a custom value in a WWW-Authenticate header.

I can't see any reason in RFC 2617 why an HTTP 401 status combined with a custom WWW-Authenticate header like this wouldn't be okay:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

The oAuth spec actually seems to do just this, as they recommend this (though they have to my mind an odd interpretation of the RFC):

WWW-Authenticate: OAuth realm="http://server.example.com/"

This doesn't appear to be specifically SANCTIONED by the RFC, but I can't actually see that it's forbidden by it (it doesn't seem to conflict with any MUST or MUST NOT, SHOULD or SHOULD NOT condition).

I wish there was a more specific HTTP status code for timeouts and for things like CSRF tokens being invalid so this was clearer.

Solution 2

I would recommend an HTTP 401.

Whereas a 403 basically says, "You're not allowed, go away and don't come back", a 401 says, "We don't know if you're allowed or not because you didn't bring your ID. Go get it and try again."

Compare Wikipedia's definitions:

HTTP 403 - The request was a legal request, but the server is refusing to respond to it.

HTTP 401 - Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided.

Solution 3

What about 419 - it is not standard, but the description on Wikipedia seems to fit:

419 Authentication Timeout

Not a part of the HTTP standard, 419 Authentication Timeout denotes that previously valid authentication has expired. It is used as an alternative to 401 Unauthorized in order to differentiate from otherwise authenticated clients being denied access to specific server resources.

Solution 4

I believe the appropriate code is going to be 403/Forbidden. There aren't any that are directly related to sessions.

Solution 5

As you post a link, in that link i found this HTTP status code 440. you can use 440 HTTP status code for session expired.

440 Login Time-out

 The client's session has expired and must log in again.

401 Unauthorized we can use when, user login credential is wrong. or auth token passed in header is invalid.

403 Forbidden we can use this when user does not has specific permission for requested resource.

So in my opinion we should use 440 Login Time-out.

View more solutions

Comments

[Jason]

Are you wanting to warn the user that the session is about to expire so the user can do something to renew it? If that's the case, it would have to be handled by a timer in JavaScript that goes off before the session timeout on the server. By the time the status code is sent by the server, it would already have expired. A timer would also be needed if you were redirecting them to another page automatically if they left the page idle.

[Tim Post]

Why, 418 of course! Short and stout ...

[sreg]

Vaadin uses 410 Gone, but since it's cachable by the browser, I would not recommend it

[AJ.]

Ah, but take a look at the rest of the definition: "The client may repeat the request without modifications at any later time." "Without modifications" would imply that a new session could be created simply by reloading/refreshing the request. In most cases, when authentication is being used, the user would have to login again first.

[marcc]

Absolutely this is the correct answer. Since the session has timed out, the request is forbidden, so this is the best choice.

[Alex Martelli]

@AJ, of course the repeated request may run into an authentication challenge (HTTP code 401) -- don't see anything in HTTP specs forbidding that, can you point to anything?

[Tim Post]

403 tells the client (basically) "Don't do that again unless you modify your request" , but if the session was established, no modification would be needed. Furthermore, you can't do anything to the (current) request to re-establish the session in most cases.

[Tim Post]

408 tells the client that they should just try re-submitting the request as is, which obviously can't work if the session has timed out.

[Brad Cupit]

408 is a 'request' timeout not session timeout. Meaning, the socket was established but was taking too long. This site does a good job explaining it: checkupdown.com/status/E408.html

[Ashith]

Exactly! 401 would be better, I think, but it requires HTTP authentication. I think this calls for a new status along the lines of 401+303 (so, obviously, 704) that means "Not Authorized, See Other to gain authorization". In addition to it being more semantically correct, it could also be the HTTP solution for trampoline redirection, basically "go here, then when you get back we'll try this again", so that the login page could be agnostic in regards to the destination.

[Iain Collins]

I can't agree with this one, RFC 2616 explicitly states that requests that result in a 403 response "SHOULD NOT be repeated" by the client and that "authorization will not help".

[toxalot]

authorization will not help - I take that to mean HTTP authentication won't help. Which is correct. Sending an Authorization header will not change anything. Neither 401 nor 403 is ideal, but I think 403 is better than 401. 401 is wrong for session timeout because RFC 2616 explicitly states client MAY repeat the request with a suitable Authorization header field. But, in this case, the client SHOULD NOT repeat the request (at least not without an interim step). Unfortunately, we can't communicate the latter part with a status code.

[anaximander]

Any idea where this comes from (other than Wikipedia)? If it's not in the official RFC, who defined it?

[toxalot]

A network connection timeout is very different from a session timeout. If you are going to use a code from a Microsoft extension, why not use 440 Login Timeout (Microsoft) as per Faisal Mq's answer

[toxalot]

401 is meant to be for HTTP authentication. RFC 2616 says response MUST include a WWW-Authenticate header field. So it's wrong to send that code without a WWW-Authenticate header field.

[David Nelson]

Not wanting to parse the response is not a good reason to deviate from the HTTP spec, especially when you can just JSON.parse(responseText).

[Salem Ouerdani]

It seems to be also removed from that wiki page

[Gareth Davidson]

That Wikipedia page about 599 was wrong and had no citations. It apparently used to say that Microsoft proxies raise 599 on network timeout, but I couldn't find any evidence of that either.

[commonpike]

Do notice apache may convert that return status to 500, as mine did - stackoverflow.com/questions/17735514/…

[Vishrant]

This is not a part of specification, neither available in Java HttpServletResponse @John if you know any other reliable source its better to reference it.

[TroySteven]

I appears to only be used in PHP Laravel

[TroySteven]

I like this solution for ASP.NET environments.

[toxalot]

I don't think using a 200 response code deviates from the HTTP spec in this case because the request was technically successful at the transport layer. To me, session timeouts are similar to form errors where I return a user-friendly error message. The disagreements expressed in the answers to this question clearly indicate that the HTTP spec does not provide an industry-accepted response code for session timeouts. How can one deviate from a spec that doesn't exist?

[8bitjunkie]

This code is specific to Microsoft IIS servers. It is not an official HTTP response code which is backed by an RFC.

[8bitjunkie]

This code is specific to Microsoft IIS servers. It is not an official HTTP response code which is backed by an RFC.

[8bitjunkie]

This code is specific to the Laravel framework. It is not an official HTTP response code which is backed by an RFC.

[Vinay Pandya]

Agree @8bitjunkie