Re: MaxInactiveInterval
On 06/11/2016 11:24, André Warnier (tomcat) wrote: > On 04.11.2016 20:06, Mark Thomas wrote: >> I did say "patches welcome" to André but since he is a committer that >> should have been "commits welcome" ;) >> > > Guys, you all know my level of (in)competence in matters deeply Java. You might be surprised at just how little Java I knew when I was made a committer. > I got my kudos by trying to help people in a general sense here, but > when things seem to involve specific parts deep down the Tomcat code, I > have to call for help. As always, happy to provide pointers. This should end up as a docs fix which I'd encourage you to consider tackling yourself. > What I know is this, from the Servlet Specs 3.0 final : > > quote > > 12. session-config Element > > The session-config defines the session parameters for this Web application. > The sub-element *session-timeout* defines the default session time out > interval > for all sessions created in this Web application. The specified time out > must be > expressed in a whole number of minutes. If the time out is 0 or less, > the container > ensures the default behavior of sessions is never to time out. If this > element is not > specified, the container must set its default time out period. > > unquote > > So it appears that there is a difference between : > - the WEB-INF/web.xml of a webapp specifying a session-timeout > 0, in > minutes > - the WEB-INF/web.xml of a webapp specifying a session-timeout =< 0 > (meaning, no timeout or "infinite") > - the WEB-INF/web.xml of a webapp not specifying a session-timeout > (container should supply a default value) > > Which thus raises the question : if a web application does not set the > session-timeout, what value is returned by Tomcat for > getMaxInactiveInterval() ? > > And the auxiliary question : can this (default) value be set somewhere > in the configuration, or is this set in code ? > > (Or is that the one that is set in (tomcat)/conf/web.xml : > > 30 > > ?) You are correct. The value from conf/web.xml provides the default if the application's web.xml does not provide one. > (and what happens if we remove that stanza from conf/web.xml ?) There is a hard-coded default of 30 minutes (i.e. the same as the explicit default in conf/web.xml) in o.a.catalina.core.StandardConetxt. All of the above assumes that the standard components are being used. Custom session managers, session implementations and/or Contexts could all modify this behaviour. To add to the fun, there is, effectively, an undocumented attribute on Context - sessionTimeout - that could also be set in server.xml / context.xml. Overall, the order of precedence should be: - application specific web.xml - conf/web.xml default - sessionTimeout attribute on Context - hard-coded default. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxInactiveInterval
On 04.11.2016 20:06, Mark Thomas wrote: On 04/11/2016 15:53, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: MaxInactiveInterval On 04/11/2016 15:07, André Warnier (tomcat) wrote: A log message in an application running under Tomcat 8 mentions the "MaxInactiveInterval" setting, saying that it is a bit short.. I think that I understand the meaning of the setting (the time for which a session remains valid, even without interactions). But where in the webapp context, and under what name, should an equivalent parameter be specified ? Set it in web.xml. Same with distributable. This really appears to be a problem in the servlet spec (not surprising), which mentions the getMaxInactiveInterval() and setMaxInactiveInterval() APIs but only vaguely ties them to the session-timeout element of session-config. Tomcat doc does not normally describe the nuances of the servlet spec, but something that associates the config name with the API might be useful. To be fair, Tomcat isn't helping here. We used to have these attributes on the (session) manager but we removed with the expectation that they would be configured in web.xml. We could have done a better job of pointing to the expected locations. I did say "patches welcome" to André but since he is a committer that should have been "commits welcome" ;) Guys, you all know my level of (in)competence in matters deeply Java. I got my kudos by trying to help people in a general sense here, but when things seem to involve specific parts deep down the Tomcat code, I have to call for help. What I know is this, from the Servlet Specs 3.0 final : quote 12. session-config Element The session-config defines the session parameters for this Web application. The sub-element *session-timeout* defines the default session time out interval for all sessions created in this Web application. The specified time out must be expressed in a whole number of minutes. If the time out is 0 or less, the container ensures the default behavior of sessions is never to time out. If this element is not specified, the container must set its default time out period. unquote So it appears that there is a difference between : - the WEB-INF/web.xml of a webapp specifying a session-timeout > 0, in minutes - the WEB-INF/web.xml of a webapp specifying a session-timeout =< 0 (meaning, no timeout or "infinite") - the WEB-INF/web.xml of a webapp not specifying a session-timeout (container should supply a default value) Which thus raises the question : if a web application does not set the session-timeout, what value is returned by Tomcat for getMaxInactiveInterval() ? And the auxiliary question : can this (default) value be set somewhere in the configuration, or is this set in code ? (Or is that the one that is set in (tomcat)/conf/web.xml : 30 ?) (and what happens if we remove that stanza from conf/web.xml ?) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.5 (8.5+) Default Cookie Processor breaks persistent cookies for all IE versions
Am 05.11.2016 um 23:58 schrieb Mark Thomas: > On 04/11/2016 19:10, Hedrick, Brooke - 43 wrote: >> Sorry if this has been already asked. I searched the archives and >> didn't find what I was looking for. > > I don't recall anyone raising it before now. > >> Has anyone else run into an issue with persistent cookies in Tomcat >> 8.5+ and IE not working? > > I can confirm I see the same issue. > >> Does it make sense that the shipping configuration would not work >> with IE for persistent cookies? > > I'll turn that around. The shipping Tomcat configuration is RFC 6265 > compliant. Does it make sense that Microsoft would ship multiple > versions of their browser for over a decade and fail to correctly > implement any of the cookie specifications that were considered current > throughout that period? (IE's cookie support is a sore point for me - I > have been dealing with IE's spec non-compliance for almost as long as I > have been working on Tomcat and it has always been unpleasant.) When I read https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/ and the last response to https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8183708/ from the Microsoft Edge Team I fear full RFC6265 support is still some years away in Microsoft world > The default Tomcat community position in cases like this is that we do > not implement workarounds for bugs in third-party code. You need to > raise a bug with the provider of the buggy code. > > We do make exceptions and they are typically for IE. Part of me thinks > that if everyone refused to work-around Microsoft's poor implementations > of various standards (WebDAV is another area that comes to mind) a) > people would see just how bad some Microsoft code really is and b) > Microsoft might come under pressure to actually fix it. > > While we could make a stand on this particular point, I suspect that > Microsoft won't even notice and all it will do is make life difficult > for our users. As annoyed as I am with Microsoft about this, making life > difficult for Tomcat users is not what this community is about. As much > as it pains me to say it, I think we are going to have to work around this. > > Maybe an new option: > enableWorkaroundForBrokenMicrosoftCookieHandling > > Seriously, we need to decide if this needs to be configurable or not. > Given that RFC6265 allows both expires and max-age to be sent and the > the legacy processor sends both by default I'm currently leaning towards > just sending both in the RFC6265 processor. +1 sending both headers Assume the following: people upgrade Tomcat and the app stops working in IE (most corporate users default browser). They will blame Tomcat - not IE. Why should we risk to damage Tomcats reputation if sending both headers is still standards compliant? This "hack" seems quite acceptable for me. Adding a configuration option for a "strict" mode would make it easier to test future browser implementations with real applications. > Assuming no-one objects, I'll aim to get this fixed for the next release > (not the one currently in progress but the one expected early next month). > > We also need to update the note in the docs about IE versions. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
