Re: Session timeouts not part of 2.2.1?

Long post warning. Unfortunately, I don't have specific proposals to 
offer at this time, but the following is a series of questions about 
server/session timeouts and what it means for them to be "a function of 
the content" vs. an exception to 2.2.1.

---------------------------------------------------------------------

I think one of the concerns we should be able to cover at level 1 here 
is a situation where the default session timeouts have been set to 
unreasonably low values.

For example, imagine a session time out for our WBS surveys of less than 
10 minutes. If the consequence of a time out was data loss rather than a 
request to re-authenticate, I think we'd all like to see this covered at 
level 1.

Even though there are cases where an author may not have control over 
the session time out setting on the server from which their content is 
served, they still (I believe) have a responsibility to ensure that the 
user can interact with their content in an accessible manner. (i.e. if 
need be, either request a change to the timeout from their sysadmin or 
move to a different host.)

I did a little bit of digging on default settings for various server 
configurations:

Apache: 30 minutes
Zope: 20 minutes
Tomcat: 30 minutes
ASP Server: 20 minutes
IIS: 10 minutes
PHP: 3 hrs.

What if the server configurations mentioned above were set to 2 minutes 
or less? Are we saying that, because the timeout is set on the server, 
it's not an accessibility barrier?

I think we also have some ambiguity around the terms "session timeout" 
vs. "server timeout."

The intent section of How to meet 2.2.1 currently talks about server 
timeouts:

[snip]
  Notes Regarding Server Timeouts

   * Timed server redirects can be found below under Common Failures.
   * Server timeouts like login expiration are dealt with in success 
criterion 2.2.6.
   * Non-timed server redirects (e.g., 3xx response codes) are not 
applicable because there is no timeout: they work instantly.

[end snip]

A note at the end of the Optional techniques section reads:

[snip]

* Using a script to poll the server and notify a user if a timeout is 
present.

Note: Where the author has no control over the server, the timeout is 
not a function of the content.
[end snip]

We also have a failure for 2.2.1 that is titled:

[snip]
Failure due to using server-side techniques to automatically redirect 
pages after a timeout.
[end snip]

Now I'm confused...

In many cases, the consequences of a session time out occurring aren't a 
significant barrier (ex. you have to log in again). Are there specific 
situations where they are (ex. when data loss occurs) and we think they 
should be covered at level 1?

Are we saying that timeouts set by a script (ex. PHP) are somehow 
different than timeouts that are set by a default configuration file in 
the server software?

If content interacts with or adjusts the default timeout setting, is it 
considered a function of the content?

What if the technology in use could easily adjust the default, but 
doesn't because the use of the default setting (theoretically not in 
their control) gives them the option to do nothing with regard to 
conformance to SC 2.2.1?

--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Wednesday, 11 January 2006 21:08:29 UTC