Erik, I should add that in the non-AJAX design, many years ago I had explored the many different response codes for our system. In short, there was no consistency.
Now with an AJAX controlled request/response system, I think one can do alittle more here. There are only a few exceptions where the BROWSER will intercept the AJAX server response and ACT accordingly. In other words, your ajax logic may not even GET a change to see interim response. I think this is true with: - 302 redirection - 401 authentication if the AUTH headers are present I think the OP in the other message was experiencing the 302 redirection and if he was attempting to load the response into a DIV container, then it is very possible (because we see it too) to have the response go to a full page. I have a bunch of exploratory code dealing with this and I believe when I last left it, I had had to use an IFRAME to contain the redirection that was forcing a full page display. Also, we have the 3 different ways a system may offer user login: - HTTP BASIC AUTH (browser prompt) - HTTP DIGEST AUTH (browser prompt) - Proprietary Cookie Based Login forms I say proprietary because there is NO STANDARD concept for cookie based login methods. So each server may offer a method and/or the backend server scripting system may offer a method. This is important in that if HTTP BASIC/DIGEST AUTH is used, this is also intercepted by the Browser AJAX request. This is good, not bad. I bring this up because in some servers, if a session timeout concept is applicatable, it MAY issue a 401 authentication request instead of some other code, like 410. This won't work with HTTP BASIC is the browser credentials is already established, but with DIGEST, it may, especially if the server is using a DIGEST + COOKIE combined authentication logic. Its a "trick" used to force the browser credentials to be released. IE 6.0 now includes a Javascript command to release credentials. -- HLS On Sep 19, 8:42 am, Pops <[EMAIL PROTECTED]> wrote: > On Sep 19, 6:22 am, "Erik Beeson" <[EMAIL PROTECTED]> wrote: > > > I know 410 isn't exactly made for this, but I'm wondering if there are > > any side effects to the technique in generally, and specifically to > > using 410. Would something else be more appropriate? Are there other > > techniques for dealing with expired sessions in a graceful way? > > Hi Erik, > > Putting my web server developer hat on I can tell ya there are many > years of practical issues and engineering here, especially when > dealing with security related ideas.. I can touch based on some ideas > but it would take a "book" to cover all the ideas. I will try to be > specific to the key points. > > Well, for starts, it will highy specific to the server in question. > The HTTP 1.1 specs for 410 eludes to those specific implementation > ideas. > > In general, you stick with HTTP 1.0 response codes and only use 1.1 > when the client is known to expect it. See the table [1] below. For > example, if you came up with jQuery Ajax plugin for 410 logic, would I > be able to use it at my server? Our server has an embedded system, > so much of a "security related" design logic would be outside the > control of any 3rd party developers - for security purposes. > > Much will also depend what "expired sessions" means. For our system, > there are various related ideas: > > - Idle Timeouts > - Out of time > - Session Applet Expired > > Again, this is embedded in the server (no PHP is or server script is > required). However, the 3rd item (Session Applet Expiration) could be > related to what you are talking about. > > An analogy would be our "New User Signup" or our Questionnaire > embedded code. > > If new accounts is enabled by the operator, a special URL alias is > made available by the server "/SIGNUP" that can be used a link on a > page. > > When clicked, this will trigger a timer where the user only has X time > to complete the signup form. > > Similarily, the operator can create questionnaire, like the default > "new user questionnaire" that is run after the initial signup and user > account is created. There too a timer is set. If the form is not > completed in time, other actions are taken. > > The idle timeout, if enabled, simply logs off the user at ther server > side. But the user can auto-login again at the next request. This > happens basically the browser remember's your credentials. The idle > timeout is basically for not chewing up user's profile daily time > allotment. > > The "out of time" is triggered if the user's daily time (if enabled) > is used up. What happens here is that any new request is automatically > redirected to another "out of time" page. > > The main point here is that it doesn't matter what URL is issued. > Because time/session management is all centralized at the back end, > you minimize any client-side security related issues. > > Taking a step back about the response code, putting my protocol > implementator hat on, historically, there is a special meaning with > the category code of the response. > > 1xx - informational > 2xx - positive responses > 3xx - informational, other action should be taken > 4xx - temporary negative response (you may try again) > 5xx - permanent negative response (don't bother to try again) > > Thats not 100% across the board, but protocols are typically design > around this old FTP originating methodology which is 100% true with > SMTP. HTTP 1.1 has these as: > > o 1xx: Informational - Request received, continuing process > > o 2xx: Success - The action was successfully received, > understood, > and accepted > > o 3xx: Redirection - Further action must be taken in order to > complete the request > > o 4xx: Client Error - The request contains bad syntax or cannot > be > fulfilled > > o 5xx: Server Error - The server failed to fulfill an apparently > valid request > > I bring this up because based on these semantics, 4xx may not be > appropiate, but maybe a 5xx. i.e, the 503 or 504 ideas that can be > explored. But that is all debatable. > > Now, that said. Do I think something can be done in this area? > > Well, I think its possible to come up with a very robust jQuery AJAX > library that deal with standard behaviors regardless of servers. > > But it will be complex to deal with specific ideas such as a "session > timeout" because each system will handles it differently. In fact, > see section 10..4.5 in the semantics for the 404 response: > > 10.4.5 404 Not Found > > The server has not found anything matching the Request-URI. No > indication is given of whether the condition is temporary or > permanent. The 410 (Gone) status code SHOULD be used if the server > knows, through some internally configurable mechanism, that an old > resource is permanently unavailable and has no forwarding address. > This status code is commonly used when the server does not wish to > reveal exactly why the request has been refused, or when no other > response is applicable. > > According to these semantics, the 410 implies the REQUEST is > permanently unavailable. But then section 10.4.11 says the maybe a 404 > should be used. Howerver, it does say that a scenario for this is > limted-time applications. > > I guess, that you can code for it (410), but not depend in it unless > you know for sure the server will be issuing this response. IMO, the > server will drive the response accordingly regardless of what the > client expects - if it has timeout a session, it doesn't matter if > its 410 or 403 or something else. It has to be handled. But I would > not use a 404 because the browser may override your response with its > own "Friendly 404 displays" like IE and FF will do. > > Phew <g> > > [1] Response codes for 1.0 and 1.1 > > 1.0 1.1 > --- --- > "100" ; X : Continue > "101" ; X : Switching Protocols > "200" ; X X : OK > "201" ; X X : Created > "202" ; X X : Accepted > "203" ; X : Non-Authoritative Information > "204" ; X X : No Content > "205" ; X X : Reset Content > "206" ; X X : Partial Content > "300" ; X : Multiple Choices > "301" ; X X : Moved Permanently > "302" ; X X : Found > "303" ; X : See Other > "304" ; X X : Not Modified > "305" ; X : Use Proxy > "307" ; X : Temporary Redirect > "400" ; X X : Bad Request > "401" ; X X : Unauthorized > "402" ; X : Payment Required > "403" ; X X : Forbidden > "404" ; X X : Not Found > "405" ; X : Method Not Allowed > "406" ; X : Not Acceptable > "407" ; X : Proxy Authentication Required > "408" ; X : Request Time-out > "409" ; X : Conflict > "410" ; X : Gone > "411" ; X : Length Required > "412" ; X : Precondition Failed > "413" ; X : Request Entity Too Large > "414" ; X : Request-URI Too Large > "415" ; X : Unsupported Media Type > "416" ; X : Requested range not satisfiable > "417" ; X : Expectation Failed > "500" ; X X : Internal Server Error > "501" ; X X : Not Implemented > "502" ; X X : Bad Gateway > "503" ; X X : Service Unavailable > "504" ; X : Gateway Time-out > "505" ; X : HTTP Version not supported > > -- > HLS
