views:

208

answers:

4

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

+2  A: 

HTTP is a state-less protocol. There really isn't a status associated with "session timeout". Since session is a concept enforced by an application server, some 5xx error would probably be most appropriate.

AJ
+2  A: 

Code 408. "Request timeout", seems perfect -- RFC 2616 explains it means

The client did not produce a request within the time that the server was prepared to wait.

i.e., exactly a "time-out", just as you require!

Alex Martelli
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.
AJ
@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?
Alex Martelli
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.
Tim Post
+3  A: 

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

Jason
Absolutely this is the correct answer. Since the session has timed out, the request is forbidden, so this is the best choice.
marcc
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
+2  A: 

If I had to pick one, I'd use a 307 (temporary redirect). Depending on how your URIs are structured, its likely that the client should continue to try the request just as they did in the future, with a current exception being that they need to login first.

Really, none of them fit the problem.

For the morbidly curious, here is the spec:

10.3.8 307 Temporary Redirect

   The requested resource resides temporarily under a different URI.
   Since the redirection MAY 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.

   The temporary URI SHOULD be given by the Location field in the
   response. Unless the request method was HEAD, the entity of the
   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s) , since many pre-HTTP/1.1 user agents do not
   understand the 307 status. Therefore, the note SHOULD contain the
   information necessary for a user to repeat the original request on
   the new URI.

   If the 307 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.
Tim Post