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
