- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Thu, 12 Jan 2006 13:39:52 +0100
- To: w3c-wai-gl@w3.org
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