Re: Session timeouts not part of 2.2.1?

At 22:08 11/01/2006, Ben Caldwell wrote:

>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 did a little bit of digging on default settings for various server 
>configurations:
>
>Apache: 30 minutes
>Zope: 20 minutes
>Tomcat: 30 minutes

In JSP/Servlets applications, you can set the default timeout for an app in 
the deployment descriptor (web.xml):
<web-app ...>
   ...
   <session-config>
    <session-timeout>40</session-timeout>
   </session-config>
   ...
</web-app>
The default timeout is defined by the servlet container (Java Servlet 
Specification 2.4, section 7.5); in Tomcat it is 30 minutes. To indicate 
that a session should never expire, use the value -1.

>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'd rather not say that, but it's what the current GL 2.2 says 
(see my comment about "function of the content" at the bottom).

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

"Session timeout" may be sufficient? Are there any reasons for using the 
term "server timeout" anywhere?

>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.

Someone should explain what a "timed server redirect" is and how it is 
implemented.
Is this mentioned here because it exist in protocols other than HTTP? In 
HTTP, I really don't see how it can be done.
As far as I know, you redirect in HTTP 1.1 by sending a 30x status code and 
a Location header with another URL as a response to the user agent. The 
user agent then reads the status code and makes a new request with the URL 
from the Location header (you can usually see this new URL in the address 
bar of the browser). The user agent will usually make this new request 
automatically. Any delays in this process are caused
- either by slow server response to the first request (which caused the 30x 
response) or the second request (with the new URL),
- or by the user agent when making the second request.
(Or maybe a slow network.)
When the server sends a 30x redirect response, it does not send a document 
in the body (at most "a short hypertext note with a hyperlink to the new 
URI(s)"). In fact, some server-side scripting technologies prevent you from 
combining a normal response and a redirect; for example, in JSP and Java 
Servlets you will get and IllegalStateException if you try to invoke 
response.sendRedirect("http://example.com") after you have committed a 
response.
So where do timed server redirects exist? Or is it a badly chosen name for 
something else? A request dispatch?

>(...)
>   * Non-timed server redirects (e.g., 3xx response codes) are not 
> applicable because there is no timeout: they work instantly.

The 30x range of reponse codes is the only one for redirects. So what could 
cause a
"timed server redirect".

>(...)
>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...

So am I, for the reasons mentioned above. Unless a server can redirect 
after a timeout in technologies other than HTTP and HTML.

>(...)
>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?

 From the previous discussions I got the impression that a timeout is a 
function of the content if it is caused by something that is in the 
delivery unit, e.g. a JavaScript in an HTML page, or the timeout attribute 
of the prompt element in VoiceXML.
Drawing a line between this category of timeouts and server-side timeouts 
because the former are under the author's control and the latter may not, 
is strictly speaking inconsistent with the goal to word success criteria as 
functional outcomes, because it does not matter to the user where the 
timeout originates. Of course, there have been other discussions about 
ideal versus reality with regard to other success criteria; I think this is 
another one.

Regards,

Christophe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Thursday, 12 January 2006 12:39:51 UTC