From dev-return-32508-archive-asf-public=cust-asf.ponee.io@geode.apache.org Wed Nov 20 17:46:46 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id A03641804BB for ; Wed, 20 Nov 2019 18:46:45 +0100 (CET) Received: (qmail 42982 invoked by uid 500); 20 Nov 2019 17:46:45 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 42964 invoked by uid 99); 20 Nov 2019 17:46:44 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Nov 2019 17:46:44 +0000 Received: from Udos-MacBook-Pro.local (50-203-225-134-static.hfc.comcastbusiness.net [50.203.225.134]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 1F5B71003 for ; Wed, 20 Nov 2019 17:46:44 +0000 (UTC) Subject: Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers To: dev@geode.apache.org References: <55A8927F-C0DB-4DCC-AF7D-5C01A409D7C7@pivotal.io> From: Udo Kohlmeyer Message-ID: <53b03138-d3b2-7cdc-1154-8b46a1365f93@apache.com> Date: Wed, 20 Nov 2019 09:46:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Thunderbird/71.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US I think that we should really be looking at going to 4.0. It would be compatible with 3.1, but given that 4.0 is standard with Java 8 (which already EOL), we should try and get onto the latest. I don't think that us aligning ourselves with a tech release in 2013 is something we should do. --Udo On 11/20/19 9:17 AM, Jens Deppe wrote: > Since there appears to be consensus, I'm going to give this thread another > 24 hours and will then consider this proposal accepted. > > If anyone does have concerns please do raise them now. > > Thanks > --Jens > > On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior wrote: > >> +1 for bumping to 3.1 >> >> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett >> wrote: >> >>> +1 for 3.1 >>> >>>> On Nov 15, 2019, at 3:08 PM, Jens Deppe wrote: >>>> >>>> +1 to bumping the documented support to 3.1. >>>> >>>> The prompting for this proposal is due to this PR which specifically >>> wants >>>> to utilize a *3.0* API: https://github.com/apache/geode/pull/4311 >>>> >>>> Thus implementing this change will not preclude being able to use the >>>> Session Module in a 3.0 container (even if we document support as being >>>> against 3.1) >>>> >>>> --Jens >>>> >>>>> On Fri, Nov 15, 2019 at 2:57 PM John Blum wrote: >>>>> >>>>> I would minimally bump it to 3.1 then. Not only does Servlet 3.1 open >>> up >>>>> more doors (e.g. NIO), but is also implemented by all current Servlet >>>>> Container providers (Tomcat, Jetty, etc). Additionally, given all the >>>>> Servlet Containers Jens mentioned at the version that started >> supporting >>>>> Servlet 3.0 are no longer supported, then 3.1 seems like a >>> good/reasonable >>>>> target. >>>>> >>>>> -j >>>>> >>>>>> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith >> wrote: >>>>>> +1 to bumping to servlet 3.0. >>>>>> >>>>>> -Dan >>>>>> >>>>>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith >>>>>> wrote: >>>>>> >>>>>>> Seems to me as long as newer Servlet specs do not deprecate >>>>>>> functionality/api that the session module requires AND that the >>> session >>>>>>> module is not missing any important functionality provided by newer >>>>>> Servlet >>>>>>> specs that it's best to base support the oldest Servlet spec that is >>>>>> still >>>>>>> supported by active container versions. As Jens nicely enumerated, >>> this >>>>>>> seems to be Servlet 3.0 right now. >>>>>>> >>>>>>> At least that's the approach that would give the session management >>>>>>> modules the widest audience. I am currently writing a Servlet 4.0 >> web >>>>> app >>>>>>> and the Geode session module is working great except that I need to >>>>> layer >>>>>>> on an additional filter to ensure my session cookies are secure. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Charles Smith >>>>>>> >>>>>>> Developer/Analyst >>>>>>> >>>>>>> Web Architecture and Development >>>>>>> MacEwan University >>>>>>> smithc14@macewan.ca >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> From: John Blum >>>>>>> Sent: Friday, November 15, 2019 11:17 AM >>>>>>> To: geode >>>>>>> Subject: Re: Proposal to modify Servlet spec support for the HTTP >>>>> Session >>>>>>> Management Module for AppServers >>>>>>> >>>>>>> Since the Servlet 3.1 spec is available and the current version is >>> 4.0, >>>>>> why >>>>>>> not consider 3.1 or even 4.0, actually? >>>>>>> >>>>>>> -j >>>>>>> >>>>>>> On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe >> wrote: >>>>>>>> Hello Charles; thanks very much for bringing this up. >>>>>>>> >>>>>>>> I vote +1 on this proposal. >>>>>>>> >>>>>>>> Just to add a bit more details for others: >>>>>>>> >>>>>>>> The 3.0 Servlet Spec was finalized at the end of 2009. The >> *earliest* >>>>>>>> versions of various containers that supported it are: >>>>>>>> >>>>>>>> - Jetty 8 (EOL'd since 11/2014) [1] >>>>>>>> - Tomcat 7 (Version 6 EOL'd 2017) [2] >>>>>>>> - JBoss Web 3.0.0 (version 2.x reached End of Maintenance >> 11/2017) >>>>>> [3] >>>>>>>> - Websphere 8.0 (End of support 4/2018) [4] >>>>>>>> - Weblogic 12cR1 (Extended Support until 12/2019) [5] >>>>>>>> >>>>>>>> The implication is that, of these products, there are *no* >> currently >>>>>>>> supported versions that *do not* support the Servlet 3.0 spec. I >>>>>> believe >>>>>>> it >>>>>>>> is quite safe for us to indicate that the Session Modules are now >>>>> only >>>>>>>> supported on 3.0 compliant containers. >>>>>>>> >>>>>>>> --Jens >>>>>>>> >>>>>>>> [1] - >>>>>>>> >> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html >>>>>>>> [2] - http://tomcat.apache.org/whichversion.html >>>>>>>> [3] - https://access.redhat.com/support/policy/updates/jboss_notes >>>>>>>> [4] - >> https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server >>>>>>>> [5] - >>>>>>>> >>>>>>>> >> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life >>>>>>>> On Fri, Nov 15, 2019 at 8:11 AM Charles Smith >>>>>> wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> The Geode HTTP Session Management Module for AppServers currently >>>>>>> states: >>>>>>>>> This approach is a generic solution, which is supported by any >>>>>>> container >>>>>>>>> that implements the Servlet 2.4 specification. >>>>>>>>> I would like to suggest that this official support be bumped up to >>>>>> the >>>>>>>>> Servlet 3.0 specification. >>>>>>>>> >>>>>>>>> There are some important cookie security features missing in the >>>>>>> ancient >>>>>>>>> Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping >>>>>> support >>>>>>>> to >>>>>>>>> Servlet 3.0 would allow the Geode AppServer session module to >>>>>>> inherently >>>>>>>>> support these session cookie security features. >>>>>>>>> >>>>>>>>> I have logged the following Jira issue: >>>>>>>>> >>>>>>>>> https://issues.apache.org/jira/browse/GEODE-7438 >>>>>>>>> >>>>>>>>> and submitted a pull request that provides the necessary support >> if >>>>>> the >>>>>>>>> Geode community agrees this is a good idea. >>>>>>>>> >>>>>>>>> And thank you for the excellent Apache Geode project! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Charles Smith >>>>>>>>> >>>>>>>>> Developer/Analyst >>>>>>>>> >>>>>>>>> Web Architecture and Development >>>>>>>>> MacEwan University >>>>>>>>> smithc14@macewan.ca >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -John >>>>>>> john.blum10101 (skype) >>>>>>> >>>>> >>>>> -- >>>>> -John >>>>> john.blum10101 (skype) >>>>> >> >> -- >> *Joris Melchior * >> CF Engineering >> Pivotal Toronto >> 416 877 5427 >> >> “Programs must be written for people to read, and only incidentally for >> machines to execute.” – *Hal Abelson* >> >>