Re: cookie configurations for Tomcat 7
Chris, Did you managed to check the PR? Lazar On Tue, Mar 10, 2020 at 5:41 PM Lazar Kirchev wrote: > Chris, > > Any update on this? Did you have a chance to have a look on the PR? > > Lazar > > On Wed, Mar 4, 2020 at 10:55 AM Lazar Kirchev > wrote: > >> Chris, Martin, >> >> Here is the PR: https://github.com/apache/tomcat/pull/252 >> >> Lazar >> >> On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov >> wrote: >> >>> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev >>> wrote: >>> >>> > Chris, >>> > >>> > I just thought that I have some concerns passing a map with the >>> headers to >>> > generateCookie() method. This means that for each call the caller will >>> have >>> > to read all headers from the coyote.Response and put them in a map, >>> even if >>> > the CookieProcessor will not need them, as is the case with the legacy >>> > cookie processor and the rfc cookie processor. This might have >>> performance >>> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request >>> - >>> > like generateCookie (Request, Cookie) - and then if the cookie >>> processor >>> > implementation needs headers, it will take them - only these which it >>> needs >>> > - from the Response. >>> > What do you think? >>> > >>> >>> I agree that this is a better way! >>> >>> Martin >>> >>> >>> > >>> > Lazar >>> > >>> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev >>> wrote: >>> > >>> > > >>> > > Chris, >>> > > >>> > > Actually in my preferred option the implementation in the >>> > > CookieProcessorBase should not be no-op, but it should call >>> > > CookieProcessor.generateCookie(Cookie). And the calls to >>> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response >>> and >>> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to >>> the >>> > new >>> > > method. >>> > > >>> > > Lazar >>> > > >>> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev < >>> lazar.kirc...@gmail.com> >>> > > wrote: >>> > > >>> > >> Chris, >>> > >> >>> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 >>> should >>> > >> be able to work both on Java 7 and Java 8, interface default methods >>> > can't >>> > >> be used. So would you prefer to have a second >>> > CookieProcessor.generateCookie(Map<> >>> > >> requestHeaders, Cookie) in addition to the existing >>> > CookieProcessor.generateCookie(Cookie), >>> > >> and provide a no-op implementation in the CookieProcessorBase >>> class, or >>> > to >>> > >> change the signature of the existing method instead? I myself >>> prefer the >>> > >> first option, with adding a second method. >>> > >> >>> > >> Lazar >>> > >> >>> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < >>> > >> ch...@christopherschultz.net> wrote: >>> > >> >>> > >>> -BEGIN PGP SIGNED MESSAGE- >>> > >>> Hash: SHA256 >>> > >>> >>> > >>> Lazar, >>> > >>> >>> > >>> On 2/24/20 02:05, Lazar Kirchev wrote: >>> > >>> > Chris, >>> > >>> > >>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will >>> > >>> > work perfectly for me and I guess for anyone who needs to check >>> the >>> > >>> > client version. >>> > >>> >>> > >>> Want to prepare a PR? >>> > >>> >>> > >>> - -chris >>> > >>> >>> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < >>> > >>> > ch...@christopherschultz.net> wrote: >>> > >>> > >>> > >>> > Lazar, >>> > >>> > >>> > >>> > On 2/21/20 10:29, Lazar Ki
Re: cookie configurations for Tomcat 7
Chris, Any update on this? Did you have a chance to have a look on the PR? Lazar On Wed, Mar 4, 2020 at 10:55 AM Lazar Kirchev wrote: > Chris, Martin, > > Here is the PR: https://github.com/apache/tomcat/pull/252 > > Lazar > > On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov > wrote: > >> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev >> wrote: >> >> > Chris, >> > >> > I just thought that I have some concerns passing a map with the headers >> to >> > generateCookie() method. This means that for each call the caller will >> have >> > to read all headers from the coyote.Response and put them in a map, >> even if >> > the CookieProcessor will not need them, as is the case with the legacy >> > cookie processor and the rfc cookie processor. This might have >> performance >> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request - >> > like generateCookie (Request, Cookie) - and then if the cookie processor >> > implementation needs headers, it will take them - only these which it >> needs >> > - from the Response. >> > What do you think? >> > >> >> I agree that this is a better way! >> >> Martin >> >> >> > >> > Lazar >> > >> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev >> wrote: >> > >> > > >> > > Chris, >> > > >> > > Actually in my preferred option the implementation in the >> > > CookieProcessorBase should not be no-op, but it should call >> > > CookieProcessor.generateCookie(Cookie). And the calls to >> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and >> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the >> > new >> > > method. >> > > >> > > Lazar >> > > >> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev < >> lazar.kirc...@gmail.com> >> > > wrote: >> > > >> > >> Chris, >> > >> >> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 >> should >> > >> be able to work both on Java 7 and Java 8, interface default methods >> > can't >> > >> be used. So would you prefer to have a second >> > CookieProcessor.generateCookie(Map<> >> > >> requestHeaders, Cookie) in addition to the existing >> > CookieProcessor.generateCookie(Cookie), >> > >> and provide a no-op implementation in the CookieProcessorBase class, >> or >> > to >> > >> change the signature of the existing method instead? I myself prefer >> the >> > >> first option, with adding a second method. >> > >> >> > >> Lazar >> > >> >> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < >> > >> ch...@christopherschultz.net> wrote: >> > >> >> > >>> -BEGIN PGP SIGNED MESSAGE- >> > >>> Hash: SHA256 >> > >>> >> > >>> Lazar, >> > >>> >> > >>> On 2/24/20 02:05, Lazar Kirchev wrote: >> > >>> > Chris, >> > >>> > >> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will >> > >>> > work perfectly for me and I guess for anyone who needs to check >> the >> > >>> > client version. >> > >>> >> > >>> Want to prepare a PR? >> > >>> >> > >>> - -chris >> > >>> >> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < >> > >>> > ch...@christopherschultz.net> wrote: >> > >>> > >> > >>> > Lazar, >> > >>> > >> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote: >> > >>> >>>> Yes, the SameSite attribute is still in a draft and this >> > >>> >>>> causes the mess, at least partly.> And yes, I was thinking >> > >>> >>>> about something like that - >> > >>> >>>> CookieProcessor.generateCookie(String userAgent, Cookie) or >> > >>> >>>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). >> > >>> >>>> I >> > >>> >
Re: cookie configurations for Tomcat 7
Chris, Martin, Here is the PR: https://github.com/apache/tomcat/pull/252 Lazar On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov wrote: > On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev > wrote: > > > Chris, > > > > I just thought that I have some concerns passing a map with the headers > to > > generateCookie() method. This means that for each call the caller will > have > > to read all headers from the coyote.Response and put them in a map, even > if > > the CookieProcessor will not need them, as is the case with the legacy > > cookie processor and the rfc cookie processor. This might have > performance > > impact. Isn't it more optimal to just pass the o.a.c.connector.Request - > > like generateCookie (Request, Cookie) - and then if the cookie processor > > implementation needs headers, it will take them - only these which it > needs > > - from the Response. > > What do you think? > > > > I agree that this is a better way! > > Martin > > > > > > Lazar > > > > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev > wrote: > > > > > > > > Chris, > > > > > > Actually in my preferred option the implementation in the > > > CookieProcessorBase should not be no-op, but it should call > > > CookieProcessor.generateCookie(Cookie). And the calls to > > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and > > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the > > new > > > method. > > > > > > Lazar > > > > > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev > > > > wrote: > > > > > >> Chris, > > >> > > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 > should > > >> be able to work both on Java 7 and Java 8, interface default methods > > can't > > >> be used. So would you prefer to have a second > > CookieProcessor.generateCookie(Map<> > > >> requestHeaders, Cookie) in addition to the existing > > CookieProcessor.generateCookie(Cookie), > > >> and provide a no-op implementation in the CookieProcessorBase class, > or > > to > > >> change the signature of the existing method instead? I myself prefer > the > > >> first option, with adding a second method. > > >> > > >> Lazar > > >> > > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < > > >> ch...@christopherschultz.net> wrote: > > >> > > >>> -BEGIN PGP SIGNED MESSAGE- > > >>> Hash: SHA256 > > >>> > > >>> Lazar, > > >>> > > >>> On 2/24/20 02:05, Lazar Kirchev wrote: > > >>> > Chris, > > >>> > > > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will > > >>> > work perfectly for me and I guess for anyone who needs to check the > > >>> > client version. > > >>> > > >>> Want to prepare a PR? > > >>> > > >>> - -chris > > >>> > > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < > > >>> > ch...@christopherschultz.net> wrote: > > >>> > > > >>> > Lazar, > > >>> > > > >>> > On 2/21/20 10:29, Lazar Kirchev wrote: > > >>> >>>> Yes, the SameSite attribute is still in a draft and this > > >>> >>>> causes the mess, at least partly.> And yes, I was thinking > > >>> >>>> about something like that - > > >>> >>>> CookieProcessor.generateCookie(String userAgent, Cookie) or > > >>> >>>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). > > >>> >>>> I > > >>> > absolutely > > >>> >>>> agree that this would be very hacky. And it might be > > >>> >>>> dangerous as CookieProcessor is an interface and there > > >>> >>>> already might be custom implementations. > > >>> > > > >>> > We can fix that with default implementations, for Java versions > > >>> > that support such thing (Java >= 1.8). > > >>> > > > >>> >>>> But can you think of another way of making the cookie > > >>> >>>>
Re: cookie configurations for Tomcat 7
Chris, I just thought that I have some concerns passing a map with the headers to generateCookie() method. This means that for each call the caller will have to read all headers from the coyote.Response and put them in a map, even if the CookieProcessor will not need them, as is the case with the legacy cookie processor and the rfc cookie processor. This might have performance impact. Isn't it more optimal to just pass the o.a.c.connector.Request - like generateCookie (Request, Cookie) - and then if the cookie processor implementation needs headers, it will take them - only these which it needs - from the Response. What do you think? Lazar On Fri, Feb 28, 2020, 17:08 Lazar Kirchev wrote: > > Chris, > > Actually in my preferred option the implementation in the > CookieProcessorBase should not be no-op, but it should call > CookieProcessor.generateCookie(Cookie). And the calls to > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the new > method. > > Lazar > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev > wrote: > >> Chris, >> >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should >> be able to work both on Java 7 and Java 8, interface default methods can't >> be used. So would you prefer to have a second >> CookieProcessor.generateCookie(Map<> >> requestHeaders, Cookie) in addition to the existing >> CookieProcessor.generateCookie(Cookie), >> and provide a no-op implementation in the CookieProcessorBase class, or to >> change the signature of the existing method instead? I myself prefer the >> first option, with adding a second method. >> >> Lazar >> >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Lazar, >>> >>> On 2/24/20 02:05, Lazar Kirchev wrote: >>> > Chris, >>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will >>> > work perfectly for me and I guess for anyone who needs to check the >>> > client version. >>> >>> Want to prepare a PR? >>> >>> - -chris >>> >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < >>> > ch...@christopherschultz.net> wrote: >>> > >>> > Lazar, >>> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote: >>> >>>> Yes, the SameSite attribute is still in a draft and this >>> >>>> causes the mess, at least partly.> And yes, I was thinking >>> >>>> about something like that - >>> >>>> CookieProcessor.generateCookie(String userAgent, Cookie) or >>> >>>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). >>> >>>> I >>> > absolutely >>> >>>> agree that this would be very hacky. And it might be >>> >>>> dangerous as CookieProcessor is an interface and there >>> >>>> already might be custom implementations. >>> > >>> > We can fix that with default implementations, for Java versions >>> > that support such thing (Java >= 1.8). >>> > >>> >>>> But can you think of another way of making the cookie >>> >>>> generation logic aware of the user agent header value? >>> > >>> > Not really. >>> > >>> > I have a preference for: >>> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) >>> > >>> > This is because User-Agent might not be the only header which is >>> > useful, here. For example, Google Chrome (amusingly enough) will >>> > be removing the User-Agent header[1] in favor of "client >>> > hints"[2]. >>> > >>> > So you might have to look at more than one header at a time, >>> > including possibly User-Agent. >>> > >>> > -chris >>> > >>> > [1] >>> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i >>> n- >>> > >>> > >>> chrome/ >>> > <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings- >>> in-chrome/ >>> <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/> >>> > >>> > >>> > [2] https://wicg.githu
Re: cookie configurations for Tomcat 7
Chris, Actually in my preferred option the implementation in the CookieProcessorBase should not be no-op, but it should call CookieProcessor.generateCookie(Cookie). And the calls to CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and o.a.c.core.ApplicationPushBuilder should be replaced with calls to the new method. Lazar On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev wrote: > Chris, > > Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should > be able to work both on Java 7 and Java 8, interface default methods can't > be used. So would you prefer to have a second > CookieProcessor.generateCookie(Map<> > requestHeaders, Cookie) in addition to the existing > CookieProcessor.generateCookie(Cookie), > and provide a no-op implementation in the CookieProcessorBase class, or to > change the signature of the existing method instead? I myself prefer the > first option, with adding a second method. > > Lazar > > On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Lazar, >> >> On 2/24/20 02:05, Lazar Kirchev wrote: >> > Chris, >> > >> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will >> > work perfectly for me and I guess for anyone who needs to check the >> > client version. >> >> Want to prepare a PR? >> >> - -chris >> >> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < >> > ch...@christopherschultz.net> wrote: >> > >> > Lazar, >> > >> > On 2/21/20 10:29, Lazar Kirchev wrote: >> >>>> Yes, the SameSite attribute is still in a draft and this >> >>>> causes the mess, at least partly.> And yes, I was thinking >> >>>> about something like that - >> >>>> CookieProcessor.generateCookie(String userAgent, Cookie) or >> >>>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). >> >>>> I >> > absolutely >> >>>> agree that this would be very hacky. And it might be >> >>>> dangerous as CookieProcessor is an interface and there >> >>>> already might be custom implementations. >> > >> > We can fix that with default implementations, for Java versions >> > that support such thing (Java >= 1.8). >> > >> >>>> But can you think of another way of making the cookie >> >>>> generation logic aware of the user agent header value? >> > >> > Not really. >> > >> > I have a preference for: >> > >> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) >> > >> > This is because User-Agent might not be the only header which is >> > useful, here. For example, Google Chrome (amusingly enough) will >> > be removing the User-Agent header[1] in favor of "client >> > hints"[2]. >> > >> > So you might have to look at more than one header at a time, >> > including possibly User-Agent. >> > >> > -chris >> > >> > [1] >> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i >> n- >> > >> > >> chrome/ >> > <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings- >> in-chrome/ >> <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/> >> > >> > >> > [2] https://wicg.github.io/ua-client-hints/ >> > >> >>>> On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz < >> >>>> ch...@christopherschultz.net> wrote: >> >>>> >> >>>> Lazar, >> >>>> >> >>>> On 2/14/20 05:36, Lazar Kirchev wrote: >> >>>>>>> Chris, >> >>>>>>> >> >>>>>>> Just FYI or in case someone else hits this problem. >> >>>>>>> >> >>>>>>> Actually I had to use the response wrapper approach >> >>>>>>> for Tomcat 8.5.50 as well. As described by Chrome in >> >>>>>>> https://www.chromium.org/updates/same-site/incompatible-clients, >> >>>>>>> >> >>>>>>> >> > >> >>>>>>> >> there are older browser versions which do not support the SameSite >> >>>>>>> attribute at all and re
Re: cookie configurations for Tomcat 7
Chris, Yes, I will prepare a PR in the next days. However, as Tomcat 8.5 should be able to work both on Java 7 and Java 8, interface default methods can't be used. So would you prefer to have a second CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) in addition to the existing CookieProcessor.generateCookie(Cookie), and provide a no-op implementation in the CookieProcessorBase class, or to change the signature of the existing method instead? I myself prefer the first option, with adding a second method. Lazar On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 2/24/20 02:05, Lazar Kirchev wrote: > > Chris, > > > > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will > > work perfectly for me and I guess for anyone who needs to check the > > client version. > > Want to prepare a PR? > > - -chris > > > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Lazar, > > > > On 2/21/20 10:29, Lazar Kirchev wrote: > >>>> Yes, the SameSite attribute is still in a draft and this > >>>> causes the mess, at least partly.> And yes, I was thinking > >>>> about something like that - > >>>> CookieProcessor.generateCookie(String userAgent, Cookie) or > >>>> CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). > >>>> I > > absolutely > >>>> agree that this would be very hacky. And it might be > >>>> dangerous as CookieProcessor is an interface and there > >>>> already might be custom implementations. > > > > We can fix that with default implementations, for Java versions > > that support such thing (Java >= 1.8). > > > >>>> But can you think of another way of making the cookie > >>>> generation logic aware of the user agent header value? > > > > Not really. > > > > I have a preference for: > > > > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) > > > > This is because User-Agent might not be the only header which is > > useful, here. For example, Google Chrome (amusingly enough) will > > be removing the User-Agent header[1] in favor of "client > > hints"[2]. > > > > So you might have to look at more than one header at a time, > > including possibly User-Agent. > > > > -chris > > > > [1] > > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i > n- > > > > > chrome/ > > <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings- > in-chrome/ > <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/> > > > > > > [2] https://wicg.github.io/ua-client-hints/ > > > >>>> On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>> > >>>> Lazar, > >>>> > >>>> On 2/14/20 05:36, Lazar Kirchev wrote: > >>>>>>> Chris, > >>>>>>> > >>>>>>> Just FYI or in case someone else hits this problem. > >>>>>>> > >>>>>>> Actually I had to use the response wrapper approach > >>>>>>> for Tomcat 8.5.50 as well. As described by Chrome in > >>>>>>> https://www.chromium.org/updates/same-site/incompatible-clients, > >>>>>>> > >>>>>>> > > > >>>>>>> > there are older browser versions which do not support the SameSite > >>>>>>> attribute at all and reject the cookies which contain > >>>>>>> it. Although Tomcat 8.5.42 and later provide the > >>>>>>> CookieProcessor configuration for the SameSite > >>>>>>> attribute, it is a problem if one wants to support > >>>>>>> older browser versions as well. > >>>> Wow, what a huge pain in the neck. I don't see anything in > >>>> RFC 6265 that says anything about rejecting cookies with > >>>> unknown attributes, but I also don't see anything prohibiting > >>>> that behavior, either. Than again, RFC 6265 doesn't mention > >>>> the SameSite attribute at all, so ... there is that. > >>>> > >>>> This is what you get when vendors try to imp
Re: cookie configurations for Tomcat 7
Chris, CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will work perfectly for me and I guess for anyone who needs to check the client version. Kind regards, Lazar On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 2/21/20 10:29, Lazar Kirchev wrote: > > Yes, the SameSite attribute is still in a draft and this causes > > the mess, at least partly.> And yes, I was thinking about something > > like that - CookieProcessor.generateCookie(String userAgent, > > Cookie) or CookieProcessor.generateCookie(Map<> requestHeaders, > > Cookie). I > absolutely > > agree that this would be very hacky. And it might be dangerous as > > CookieProcessor is an interface and there already might be custom > > implementations. > > We can fix that with default implementations, for Java versions that > support such thing (Java >= 1.8). > > > But can you think of another way of making the cookie generation > > logic aware of the user agent header value? > > Not really. > > I have a preference for: > > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) > > This is because User-Agent might not be the only header which is > useful, here. For example, Google Chrome (amusingly enough) will be > removing the User-Agent header[1] in favor of "client hints"[2]. > > So you might have to look at more than one header at a time, including > possibly User-Agent. > > - -chris > > [1] > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in- > chrome/ > <https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/> > > [2] https://wicg.github.io/ua-client-hints/ > > > On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Lazar, > > > > On 2/14/20 05:36, Lazar Kirchev wrote: > >>>> Chris, > >>>> > >>>> Just FYI or in case someone else hits this problem. > >>>> > >>>> Actually I had to use the response wrapper approach for > >>>> Tomcat 8.5.50 as well. As described by Chrome in > >>>> https://www.chromium.org/updates/same-site/incompatible-clients, > >>>> > >>>> > there are older browser versions which do not support the SameSite > >>>> attribute at all and reject the cookies which contain it. > >>>> Although Tomcat 8.5.42 and later provide the CookieProcessor > >>>> configuration for the SameSite attribute, it is a problem if > >>>> one wants to support older browser versions as well. > > Wow, what a huge pain in the neck. I don't see anything in RFC > > 6265 that says anything about rejecting cookies with unknown > > attributes, but I also don't see anything prohibiting that > > behavior, either. Than again, RFC 6265 doesn't mention the SameSite > > attribute at all, so ... there is that. > > > > This is what you get when vendors try to implement standards > > before they are standards. > > > >>>> Adding the SameSite attribute in order to support newest > >>>> Chrome breaks the old ones as the configuration via the > >>>> CookieProcessor does not allow for user agent sniffing. Even > >>>> if you extend the existing CookieProcessor implementations or > >>>> create your own, you cannot get the request headers in it so > >>>> that you can check for the browser version. If one needs such > >>>> flexibility, only the response wrapper helps. Do you think > >>>> that it makes sense to provide a mechanism in the > >>>> CookieProcessor to get access to the request headers in order > >>>> to check the user agent? > > Are you referring to CookieProcessor.generateCookie(Cookie)? So > > the proposal would be to change that to > > CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe > > even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)? > > > > It seems super hacky to do it that way, but I'm not sure I see > > another option for introducing SameSite in a compatible way. > > > > -chris > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > >
Re: cookie configurations for Tomcat 7
Chris, Yes, the SameSite attribute is still in a draft and this causes the mess, at least partly. And yes, I was thinking about something like that - CookieProcessor.generateCookie(String userAgent, Cookie) or CookieProcessor.generateCookie(Map<> requestHeaders, Cookie). I absolutely agree that this would be very hacky. And it might be dangerous as CookieProcessor is an interface and there already might be custom implementations. But can you think of another way of making the cookie generation logic aware of the user agent header value? Lazar On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 2/14/20 05:36, Lazar Kirchev wrote: > > Chris, > > > > Just FYI or in case someone else hits this problem. > > > > Actually I had to use the response wrapper approach for Tomcat > > 8.5.50 as well. As described by Chrome in > > https://www.chromium.org/updates/same-site/incompatible-clients, > > there are older browser versions which do not support the SameSite > > attribute at all and reject the cookies which contain it. Although > > Tomcat 8.5.42 and later provide the CookieProcessor configuration > > for the SameSite attribute, it is a problem if one wants to > > support older browser versions as well. > Wow, what a huge pain in the neck. I don't see anything in RFC 6265 > that says anything about rejecting cookies with unknown attributes, > but I also don't see anything prohibiting that behavior, either. Than > again, RFC 6265 doesn't mention the SameSite attribute at all, so ... > there is that. > > This is what you get when vendors try to implement standards before > they are standards. > > > Adding the SameSite attribute in order to support newest Chrome > > breaks the old ones as the configuration via the CookieProcessor > > does not allow for user agent sniffing. Even if you extend the > > existing CookieProcessor implementations or create your own, you > > cannot get the request headers in it so that you can check for the > > browser version. If one needs such flexibility, only the response > > wrapper helps. Do you think that it makes sense to provide a > > mechanism in the CookieProcessor to get access to the request > > headers in order to check the user agent? > Are you referring to CookieProcessor.generateCookie(Cookie)? So the > proposal would be to change that to > CookieProcessor.generateCookie(String userAgent, Cookie)? Or maybe > even CookieProcessor.generateCookie(Map<> rquestHeaders, Cookie)? > > It seems super hacky to do it that way, but I'm not sure I see another > option for introducing SameSite in a compatible way. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5G7hcACgkQHPApP6U8 > pFhBGg//fPcTiL5fYRfVKB7IbRe/T43UNIVzWYugujVQnJTP+owJnQvSXXPhvQgB > jJNNvuIyiqw03Z4EpychSaq9r0f1YHsp7cVkScu+vRPXR5B70Ny4vzSf0sNrFXSz > K2pDBIE7FlxhmBjdXaIAZbcmZKPQKbcpUWes898Ichh4XlBl5Ij2ZGYf86jENsoB > dFSc+pyMHjDrGilUcCDi6VNthJauB0JegTpm7Iwh1zJ64u9LgAcxHmfVkpz1RVUD > bL+c/WmEPBET1ebYy3tBmJXXbdqmDzJbMubYJYe5uDi1cseUmhiUhhk0I5M/DSeo > CCLelrHCcD8JJ049aLNOFXLNgiUquoe+zFlqlecNxI+6LzOEPUeYHCiAg6XqKggx > uCxcjEq6RTP8xHfRsVgk1r9X0pS/Zjhp9EPAN9LUc+QoC0MW8+ZwgsnSrIXVOfPa > Ln+NV+3Ve3F3vBi+apdoCq2U5I1K2Q0YYGiZyHknIWfqXtM1jycylcn2F0YZ/VMn > l1E6tkOb2owdnf6QJkcWibFFiEpWZqj9PsOipj/IQBaBAYOW4wMK6q2USU6reNGK > IjQ3aWJjPOaHSfqCPlxeAUW8lIsHkgtjJmX4zzXEOOpgIulMWzpDX8Ia1ItXLqVH > HPdI0j9I+Dl9tjRhLyy1FL2M7WNPFLhBD9qhJ9Eeli8SCtIAEzc= > =tR3G > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: cookie configurations for Tomcat 7
Chris, Just FYI or in case someone else hits this problem. Actually I had to use the response wrapper approach for Tomcat 8.5.50 as well. As described by Chrome in https://www.chromium.org/updates/same-site/incompatible-clients, there are older browser versions which do not support the SameSite attribute at all and reject the cookies which contain it. Although Tomcat 8.5.42 and later provide the CookieProcessor configuration for the SameSite attribute, it is a problem if one wants to support older browser versions as well. Adding the SameSite attribute in order to support newest Chrome breaks the old ones as the configuration via the CookieProcessor does not allow for user agent sniffing. Even if you extend the existing CookieProcessor implementations or create your own, you cannot get the request headers in it so that you can check for the browser version. If one needs such flexibility, only the response wrapper helps. Do you think that it makes sense to provide a mechanism in the CookieProcessor to get access to the request headers in order to check the user agent? Kind regards, Lazar On Tue, Feb 4, 2020 at 5:54 PM Lazar Kirchev wrote: > Thanks a lot Chris! I wish I could just get away from Tomcat 7 and upgrade > to 8.5, but I can't. Yes, the response wrapping will do. > > Lazar > > On Mon, Feb 3, 2020 at 4:30 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Lazar, >> >> On 2/3/20 5:42 AM, Lazar Kirchev wrote: >> > Chris, >> > >> > With "having control on the server but not on the application" I >> > meant that I could make changes on the server, but I have no >> > control to make modification on the application code. My concern >> > with the changed Chrome behavior regarding the same site cookie >> > attribute (https://www.chromestatus.com/feature/5088147346030592) >> > is that assuming "lax" as default value of the same site attribute >> > would break some specific authentication scenarios. Here I am >> > concerned particularly with the same site attribute of the >> > JSESSIONID cookie. >> >> Do you need your JSESSIONIDs to be sent to domains other than the one >> where the application actually lives? The whole same-site thing exists >> to fix some corner-cases in cookie theft. A "typical" application >> should not need any intervention, I think. >> >> > In a valve I can modify a header when the valve is invoked and >> > before it calls the next valve in the chain, but at that time the >> > JSESSIONID cookie may not be issued yet. >> >> There are other options. >> >> > And when the control comes back to the valve on the way back it may >> > be too late to change the header value. >> >> There are other options. >> >> > In Tomcat 8 and above the same site attribute can be specified as >> > a configuration to the CookieProcessor implementation. Is it >> > possible to achieve this reliably in Tomcat 7? >> >> Not with Tomcat's code. This does not appear to have been back-ported. >> >> I think you have two options: >> >> 1. Upgrade to Tomcat 8.5 (it's less painful than you might think) >> >> 2. Write a Valve and install it in the application: >> - For each request >> a. Wrap the response object in a wrapper class you write >> b. Dispatch the request as usual, using your response wrapper >> - Your wrapper class should: >> a. Extend o.a.c.connector.Response >> b. Override generateCookieString(Cookie) >> c. Call the superclass method, mutate as necessary >> d. Return the massaged cookie string >> >> I'm not sure which of those you consider riskier for your environment. >> You are cutting it a little close (chrome 80 is scheduled to be stable >> tomorrow). >> >> - -chris >> >> > Lazar, >> > >> > On 1/30/20 12:25 PM, Lazar Kirchev wrote: >> >>>> The problem is that I cannot make it from within the >> >>>> application. I have no control on the application, only on >> >>>> the server, so I have to be able to set the cookie either in >> >>>> a server configuration or in a component which will reside in >> >>>> the server. >> > >> > It's not clear to me what you mean by "server". Usually, the >> > application runs on the server, so if you only have control of the >> > server... you have control of the application. >> > >> >>>> I am concerned particularl
Re: cookie configurations for Tomcat 7
Thanks a lot Chris! I wish I could just get away from Tomcat 7 and upgrade to 8.5, but I can't. Yes, the response wrapping will do. Lazar On Mon, Feb 3, 2020 at 4:30 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 2/3/20 5:42 AM, Lazar Kirchev wrote: > > Chris, > > > > With "having control on the server but not on the application" I > > meant that I could make changes on the server, but I have no > > control to make modification on the application code. My concern > > with the changed Chrome behavior regarding the same site cookie > > attribute (https://www.chromestatus.com/feature/5088147346030592) > > is that assuming "lax" as default value of the same site attribute > > would break some specific authentication scenarios. Here I am > > concerned particularly with the same site attribute of the > > JSESSIONID cookie. > > Do you need your JSESSIONIDs to be sent to domains other than the one > where the application actually lives? The whole same-site thing exists > to fix some corner-cases in cookie theft. A "typical" application > should not need any intervention, I think. > > > In a valve I can modify a header when the valve is invoked and > > before it calls the next valve in the chain, but at that time the > > JSESSIONID cookie may not be issued yet. > > There are other options. > > > And when the control comes back to the valve on the way back it may > > be too late to change the header value. > > There are other options. > > > In Tomcat 8 and above the same site attribute can be specified as > > a configuration to the CookieProcessor implementation. Is it > > possible to achieve this reliably in Tomcat 7? > > Not with Tomcat's code. This does not appear to have been back-ported. > > I think you have two options: > > 1. Upgrade to Tomcat 8.5 (it's less painful than you might think) > > 2. Write a Valve and install it in the application: > - For each request > a. Wrap the response object in a wrapper class you write > b. Dispatch the request as usual, using your response wrapper > - Your wrapper class should: > a. Extend o.a.c.connector.Response > b. Override generateCookieString(Cookie) > c. Call the superclass method, mutate as necessary > d. Return the massaged cookie string > > I'm not sure which of those you consider riskier for your environment. > You are cutting it a little close (chrome 80 is scheduled to be stable > tomorrow). > > - -chris > > > Lazar, > > > > On 1/30/20 12:25 PM, Lazar Kirchev wrote: > >>>> The problem is that I cannot make it from within the > >>>> application. I have no control on the application, only on > >>>> the server, so I have to be able to set the cookie either in > >>>> a server configuration or in a component which will reside in > >>>> the server. > > > > It's not clear to me what you mean by "server". Usually, the > > application runs on the server, so if you only have control of the > > server... you have control of the application. > > > >>>> I am concerned particularly with the SameSite attribute of > >>>> the JSESSIONID cookie because of the new behavior of Chrome > >>>> 80 - https://www.chromestatus.com/feature/5088147346030592 > > > > What is your specific concern? > > > >>>> I was considering to have a valve which modifies the > >>>> Set-Cookie header. But I if the application flushes the > >>>> output stream the headers will be written to the socket and > >>>> the valve will not have the chance to modify the cookie. > > You can use a which can intercept the calls to > > setHeader(), etc. to correct the header value. > > > > Which cookie are you trying to modify? > > > > -chris > > > >>>> On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>> > >>>> John, > >>>> > >>>> On 1/27/20 9:37 AM, John Dale wrote: > >>>>>>> Over the years I found it more productive to manage my > >>>>>>> own headers for the most part. > >>>>>>> > >>>>>>> The key for us has been keeping the code clean and > >>>>>>> manageable. > >>>> > >>>> +1 > >>>> > >>>>
Re: cookie configurations for Tomcat 7
Chris, With "having control on the server but not on the application" I meant that I could make changes on the server, but I have no control to make modification on the application code. My concern with the changed Chrome behavior regarding the same site cookie attribute (https://www.chromestatus.com/feature/5088147346030592) is that assuming "lax" as default value of the same site attribute would break some specific authentication scenarios. Here I am concerned particularly with the same site attribute of the JSESSIONID cookie. In a valve I can modify a header when the valve is invoked and before it calls the next valve in the chain, but at that time the JSESSIONID cookie may not be issued yet. And when the control comes back to the valve on the way back it may be too late to change the header value. In Tomcat 8 and above the same site attribute can be specified as a configuration to the CookieProcessor implementation. Is it possible to achieve this reliably in Tomcat 7? Lazar On Fri, Jan 31, 2020 at 6:03 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 1/30/20 12:25 PM, Lazar Kirchev wrote: > > The problem is that I cannot make it from within the application. I > > have no control on the application, only on the server, so I have > > to be able to set the cookie either in a server configuration or in > > a component which will reside in the server. > > It's not clear to me what you mean by "server". Usually, the > application runs on the server, so if you only have control of the > server... you have control of the application. > > > I am concerned particularly with the SameSite attribute of the > > JSESSIONID cookie because of the new behavior of Chrome 80 - > > https://www.chromestatus.com/feature/5088147346030592 > > What is your specific concern? > > > I was considering to have a valve which modifies the Set-Cookie > > header. But I if the application flushes the output stream the > > headers will be written to the socket and the valve will not have > > the chance to modify the cookie. > You can use a which can intercept the calls to setHeader(), > etc. to correct the header value. > > Which cookie are you trying to modify? > > - -chris > > > On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > John, > > > > On 1/27/20 9:37 AM, John Dale wrote: > >>>> Over the years I found it more productive to manage my own > >>>> headers for the most part. > >>>> > >>>> The key for us has been keeping the code clean and > >>>> manageable. > > > > +1 > > > > But there isn't any reason not to use Tomcat's header parsing. If > > you have anything that could be considered odd, you should encode > > it in a safe way that doesn't require that you play other games > > with the cookie value. > > > > For example, base64 encoding a cookie value should make it > > header-safe, as long as you make sure to use a base64 encoder that > > doesn't add newlines. > > > > -chris > > > >>>> On 1/27/20, Lazar Kirchev wrote: > >>>>> Hello, > >>>>> > >>>>> In Tomcat >= 8 there is the CookieProcessor in which > >>>>> cookie configurations could be made, including for SameSite > >>>>> cookie. Is there any way to configure this in Tomcat 7? Or > >>>>> the only way is to configure it manually in code? > >>>>> > >>>>> Kind regards, Lazar > >>>>> > >>>> > >>>> --- > - -- > >>>> > >>>> > > > >>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: > >>>> users-h...@tomcat.apache.org > >>>> > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl40T9gACgkQHPApP6U8 > pFhtmxAAgbipkJUvbAl5RkPw0/F2jXhUD03TRqD1fouMaVDWx+FcbhbMXxcrYQpA > XYvkRZKj2xbpaKz1Kmy0dSTwBTlJU2ZC8/ZosxGC8c0MBqXyEgxdC0/1zPN0u03j > Oa/L8nl+MNlHcA9OFtj8
Re: cookie configurations for Tomcat 7
The problem is that I cannot make it from within the application. I have no control on the application, only on the server, so I have to be able to set the cookie either in a server configuration or in a component which will reside in the server. I am concerned particularly with the SmaeSite attribute of the JSESSIONID cookie because of the new behavior of Chrome 80 - https://www.chromestatus.com/feature/5088147346030592. I was considering to have a valve which modifies the Set-Cookie header. But I if the application flushes the output stream the headers will be written to the socket and the valve will not have the chance to modify the cookie. Lazar On Tue, Jan 28, 2020 at 5:27 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 1/27/20 9:37 AM, John Dale wrote: > > Over the years I found it more productive to manage my own headers > > for the most part. > > > > The key for us has been keeping the code clean and manageable. > > +1 > > But there isn't any reason not to use Tomcat's header parsing. If you > have anything that could be considered odd, you should encode it in a > safe way that doesn't require that you play other games with the > cookie value. > > For example, base64 encoding a cookie value should make it > header-safe, as long as you make sure to use a base64 encoder that > doesn't add newlines. > > - -chris > > > On 1/27/20, Lazar Kirchev wrote: > >> Hello, > >> > >> In Tomcat >= 8 there is the CookieProcessor in which cookie > >> configurations could be made, including for SameSite cookie. Is > >> there any way to configure this in Tomcat 7? Or the only way is > >> to configure it manually in code? > >> > >> Kind regards, Lazar > >> > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wUtwACgkQHPApP6U8 > pFi+NRAAhLyyE3tQuxUnkDEfBWD/myhclfgBtij85I/ovcYKqG1vZ13k4il4Ti2u > eybk7C59WXnoaoiCL59JU/fC3a+p/hnK404FEH51iQ6TybSOC4BQjrzojiDCKSgi > w0enCMkmbrEJNAYmg9SH4aqtet1tbxSMTjvEwHCxog3W1LEFeB2GXz9zvxyUQ82m > Z1cSVjPn0sgzlV1UwABJnnxxveke2oH+CXpNtWR4eY/EjO3aC/sHfHJPyxNGFfUy > xiT+S8Mv5K53M5Uz4+CGDIUWpu1/IwhRCtrS4FynMgm+l+ukPkdh96tlEfHx4mUF > k+qo7vLcpq674QyYfPw94vRJ2BolwnoEtvPpIpNGa96QP1otP5WbJo+msr49pa/h > +KLVw/nByH6+lv/K/Zt2bL/emKwoc+0Zb7eqEdJnOPBMXyXlSqoU5XHxpc6UFNA/ > zCjXCRV/A0pXuHZDFXpjKS0tnwDj7fUsPuHHK8kol10ZhjZ672NLoXt5sFMiqXk9 > tWk2bnUfTxxJaO13g86bIKLIch2UiSw2Dtg3qtbEHjm1VxTEscaJnFkX5I606x2d > LW9dNhnBG4bEOt22sCb+iI5duw5HezDPVNUN4AsHizu3bZQlJIt/dOHJFXppyCfm > 53+tZGs9veAG8Vlz3/DbLdTod92pxX6gGbmjJsU3TonPc4mMdNY= > =UIAx > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
cookie configurations for Tomcat 7
Hello, In Tomcat >= 8 there is the CookieProcessor in which cookie configurations could be made, including for SameSite cookie. Is there any way to configure this in Tomcat 7? Or the only way is to configure it manually in code? Kind regards, Lazar
Re: Fix for DBCP-518
Great, thanks a lot Mark! On Fri, May 3, 2019 at 9:42 PM Mark Thomas wrote: > On 26/04/2019 17:27, Mark Thomas wrote: > > On 24/04/2019 16:28, Lazar Kirchev wrote: > >> Hello, > >> > >> Any update on this? > > > > No specific plans but I can do an update of DBCP2, Pool2 etc for the > > next set of releases. > > I've just pushed the commits for this. It will be included in 8.5.41 > onwards. > > Mark > > > > > > Mark > > > > > >> > >> Regards, > >> Lazar > >> > >> On Tue, Apr 16, 2019 at 4:28 PM Lazar Kirchev > >> wrote: > >> > >>> Hello, > >>> > >>> Do you have any plans to get the fix for > >>> https://issues.apache.org/jira/browse/DBCP-518 in the Tomcat 8.5 > clone of > >>> the Commons DBCP? > >>> The commits with the fix are > >>> > https://github.com/apache/commons-dbcp/commit/81aea944160608838cb2d7cdfb0d9b6893a655d9 > , > >>> > >>> > https://github.com/apache/commons-dbcp/commit/3449a42bbaeed0ff5b0d07998169ff2896bf45c7 > >>> and > >>> > https://github.com/apache/commons-dbcp/commit/91f7e267e61047614751763f6c5968a1ff65f82c > >>> > >>> Regards, > >>> Lazar > >>> > >> > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Fix for DBCP-518
Hello, Any update on this? Regards, Lazar On Tue, Apr 16, 2019 at 4:28 PM Lazar Kirchev wrote: > Hello, > > Do you have any plans to get the fix for > https://issues.apache.org/jira/browse/DBCP-518 in the Tomcat 8.5 clone of > the Commons DBCP? > The commits with the fix are > https://github.com/apache/commons-dbcp/commit/81aea944160608838cb2d7cdfb0d9b6893a655d9, > > https://github.com/apache/commons-dbcp/commit/3449a42bbaeed0ff5b0d07998169ff2896bf45c7 > and > https://github.com/apache/commons-dbcp/commit/91f7e267e61047614751763f6c5968a1ff65f82c > > Regards, > Lazar >
Fix for DBCP-518
Hello, Do you have any plans to get the fix for https://issues.apache.org/jira/browse/DBCP-518 in the Tomcat 8.5 clone of the Commons DBCP? The commits with the fix are https://github.com/apache/commons-dbcp/commit/81aea944160608838cb2d7cdfb0d9b6893a655d9, https://github.com/apache/commons-dbcp/commit/3449a42bbaeed0ff5b0d07998169ff2896bf45c7 and https://github.com/apache/commons-dbcp/commit/91f7e267e61047614751763f6c5968a1ff65f82c Regards, Lazar
Re: Supported callbacks in Tomcat JASPIC implementation
Thanks Chris, Mark, I opened an enhancement request about a configurable callback handler - https://bz.apache.org/bugzilla/show_bug.cgi?id=61795 I have included in it a pull request with patch proposal. Regards, Lazar On Mon, Nov 20, 2017 at 4:24 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Mark and Lazar, > > On 11/18/17 10:05 AM, Mark Thomas wrote: > > On 18/11/17 14:20, Lazar Kirchev wrote: > >> Hello Marc, > >> > >> Do you think it makes sense to make the CallbackHandler > >> implementation class configurable, e.g. to be able to specify its > >> name via a property? > > > > As a property on the authenticator? I don't see why not. > > +1 > > Also, we should arrange to allow for multiple callback handlers to be > supported. > > >> In this way if support for additional callbacks is necessary > >> someone could plug a custom CallbackHandler providing such a > >> support. The current CallbackHandlerImpl would remain the default > >> one. > >> > >> Regarding jaspic, as I played around a little bit with it I found > >> the following small problems (all bugzilla issues contain also a > >> pull request with a patch proposal): > > Fantastic! Thanks for your contributions! > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloS5YkACgkQHPApP6U8 > pFgznxAAl7+ujEV0K520FcIckJFnz8qLnoTRBz5qlCVFJOBAUVBbNL9zJTUs/n6K > /EOVEWmvB26reIvyxprw9UXbhtanukpmYrQ6DWpPsH03z6WIQJhmZ4BXw+XJklJS > YE2A3GldT0+wgArSM00bHjDR6gZaHPuTutO9Gpk0su9uw1Erd41dNj53tYqQ9254 > pNqhS+tsI8ayQ7zMrNHIzR/C/beS3IOURyyAxHL7wGMGBq83O6+l8u0tTzR5+j0t > vFLHa1Q6uVAkofJmOzXehBbX3k7wU6HQdSIXZWcEG8Qhn6i8sjfXJw8cRf7YOIYY > Ou5smdWPWEcnQlYDIUwyMx6+/yXhgUgV6chai+tFsNBLlMjNBCjhVmqXB1Jc9kPK > fRo6KmcPTaCBip5qk4QdtenY7/5Swi+y9SFKu4AXTxsWx2MvVO/Xupp3RsYocybT > 8V8UNmTGbxgRUMyFLjCFN5rPwt6OvgCPle99rMJXtWObGZFdiVL7RhLhoh9mXl8D > tUyATSWG+etqn6xn5VlnI9si10hvPcgkWfPn+nEIEWQAbjoi5UP0f2BaFdk3mX8+ > t+m+AKup3eiHlSxI/YCwotSQ6+3W7AuSPsZ+O31AFAid54zkw7ZUGniYC4w5wwtq > oxIrCOJAmWGbIWotCNlqTm8liV9FhtpzYkNvG/eFIxv9rtsuYm4= > =McTq > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Supported callbacks in Tomcat JASPIC implementation
> Do you think it makes sense to make the CallbackHandler implementation > > class configurable, e.g. to be able to specify its name via a property? > > As a property on the authenticator? I don't see why not. Yes, something like that: https://github.com/apache/tomcat/pull/93 > > In > > this way if support for additional callbacks is necessary someone could > > plug a custom CallbackHandler providing such a support. The current > > CallbackHandlerImpl would remain the default one. > > > > Regarding jaspic, as I played around a little bit with it I found the > > following small problems (all bugzilla issues contain also a pull request > > with a patch proposal): > > Thanks. Hopefully they'll get looked at before the next set of releases. Thanks. I don't think they are very urgent so it will be OK even if they go in some later release. Regards, Lazar
Re: Supported callbacks in Tomcat JASPIC implementation
Hello Marc, Do you think it makes sense to make the CallbackHandler implementation class configurable, e.g. to be able to specify its name via a property? In this way if support for additional callbacks is necessary someone could plug a custom CallbackHandler providing such a support. The current CallbackHandlerImpl would remain the default one. Regarding jaspic, as I played around a little bit with it I found the following small problems (all bugzilla issues contain also a pull request with a patch proposal): https://bz.apache.org/bugzilla/show_bug.cgi?id=61777 https://bz.apache.org/bugzilla/show_bug.cgi?id=61778 https://bz.apache.org/bugzilla/show_bug.cgi?id=61779 https://bz.apache.org/bugzilla/show_bug.cgi?id=61780 https://bz.apache.org/bugzilla/show_bug.cgi?id=61781 https://bz.apache.org/bugzilla/show_bug.cgi?id=61782 https://bz.apache.org/bugzilla/show_bug.cgi?id=61783 https://bz.apache.org/bugzilla/show_bug.cgi?id=61784 All fixes are really very small. Regards, Lazar On Wed, Nov 8, 2017 at 5:51 PM, Lazar Kirchev <lazar.kirc...@gmail.com> wrote: > Yes, my mistake - 3.5, not 4.5. But the content is the same. > > Thanks Mark! > > On Wed, Nov 8, 2017 at 5:38 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 08/11/2017 12:00, Lazar Kirchev wrote: >> > Hello, >> > >> > According to the JASSPIC spec version 1.1, chapter 4.5, The >> CallbackHandler >> > should support CallerPrincipalCallback, GroupPrincipalCallback, >> > PasswordValidationCallback, as well as CertStoreCallback, >> > PrivateKeyCallback, SecretKeyCallback and TrustStoreCallback. >> >> Chapter 4 is the SOAP profile. >> >> You want to look at Chapter 3 which is the Servlet Container profile. >> >> > However, in Tomcat 8.5.* >> > org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl supports >> only >> > CallerPrincipalCallback and GroupPrincipalCallback. Are there any plans >> to >> > add support for the others? >> >> There are no plans to extend the JASPIC implementation at this time. >> >> Patches welcome. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Supported callbacks in Tomcat JASPIC implementation
Yes, my mistake - 3.5, not 4.5. But the content is the same. Thanks Mark! On Wed, Nov 8, 2017 at 5:38 PM, Mark Thomas <ma...@apache.org> wrote: > On 08/11/2017 12:00, Lazar Kirchev wrote: > > Hello, > > > > According to the JASSPIC spec version 1.1, chapter 4.5, The > CallbackHandler > > should support CallerPrincipalCallback, GroupPrincipalCallback, > > PasswordValidationCallback, as well as CertStoreCallback, > > PrivateKeyCallback, SecretKeyCallback and TrustStoreCallback. > > Chapter 4 is the SOAP profile. > > You want to look at Chapter 3 which is the Servlet Container profile. > > > However, in Tomcat 8.5.* > > org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl supports > only > > CallerPrincipalCallback and GroupPrincipalCallback. Are there any plans > to > > add support for the others? > > There are no plans to extend the JASPIC implementation at this time. > > Patches welcome. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Supported callbacks in Tomcat JASPIC implementation
Hello, According to the JASSPIC spec version 1.1, chapter 4.5, The CallbackHandler should support CallerPrincipalCallback, GroupPrincipalCallback, PasswordValidationCallback, as well as CertStoreCallback, PrivateKeyCallback, SecretKeyCallback and TrustStoreCallback. However, in Tomcat 8.5.* org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl supports only CallerPrincipalCallback and GroupPrincipalCallback. Are there any plans to add support for the others? Regards, Lazar
Re: Default response charset
Thanks a lot Mark! On Wed, Oct 25, 2017 at 12:51 PM, Mark Thomas <ma...@apache.org> wrote: > On 25/10/17 10:23, Mark Thomas wrote: > > On 24/10/17 07:36, Lazar Kirchev wrote: > >> Hello, > >> > >> Change http://svn.apache.org/viewvc?view=revision=1801052 > tries, > >> in case no charset is specified for the response, to determine a default > >> one based on the content language if such is present. For en and fr > >> languages the ISO-8859-1 charset is used as default. > > > > There is slightly more to it than that. > > > > If the application sets the "Content-Language" header then Tomcat > > extracts the Locale from that header and calls setLocale(). > > > > This behaviour is not required by the specification but is one of a > > number of cases where Tomcat tries to map the explicit setting of HTTP > > headers to Servlet API calls. "Content-Type" and "Content-Length" are > > the others. > > Hmm. Looking at Tomcat 9 that code is no longer there. It isn't there in > 8.0.x either. Digging in the svn history the "Content-Language" handling > was removed (r1374824) shortly after it was added (r1374073). The commit > message doesn't explain why. > > Time to check the mail archives... > > ... and here is the thread: > http://tomcat.markmail.org/thread/qhnzq7v3dopgi7uz > > Having reviewed that thread, I don't see anything that has really > changed since 2012. On that basis I'll remove "Content-Language" > handling from 7.0.x to align it with the other versions. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Default response charset
Hello, Change http://svn.apache.org/viewvc?view=revision=1801052 tries, in case no charset is specified for the response, to determine a default one based on the content language if such is present. For en and fr languages the ISO-8859-1 charset is used as default. However, this is done for all content types, not only for text media types. Is this intentional? For example, for some media types (particularly application/json) this could lead to incorrect representation of characters. Kind regards, Lazar
Tomcat 8 slow shutdown on Windows 10
Hello, I am observing slow shutdown of Tomcat 8 on Windows 10 - some 9 - 11 seconds. I observed this first with Tomcat 8.5.16, but then checked it on older versions and I found the same from 8.5.11 onward. Before that it stops for less than a second. Most time is spent in stopping the protocol handlers - about 2 seconds for each. Profiling shows that the waiting is in the java.net.NetworkInterface.getNetworkInterfaces() method in AbstractEndpoint class. However, one strange thing is that I observe this behavior when I am connected to one network, bot on another network the delay is not observed and the server stops for less than a second. Has anybody experienced similar problems? Regards, Lazar
Re: Issue when the Content-Type request header specifies invalid charset
Thanks Mark, Here is the issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=61264 Lazar On Fri, Jul 7, 2017 at 11:22 AM, Mark Thomas <ma...@apache.org> wrote: > On 07/07/17 08:44, Lazar Kirchev wrote: > > Hello, > > > > Prior to Tomcat 8.5.15 if the Content-Type request header specifies an > > invalid charset, then the HttpServletRequest.getReader() throws a > > UnsupportedEncodingException (from its javadoc:it should throw such an > > exception if the character set encoding used is not supported and the > text > > cannot be decoded). > > > > However, in Tomcat 8.5.15, with change > > https://github.com/apache/tomcat85/commit/18e70aff0fd3e9195d2bf01e445c49 > ea9fd44d0b > > this exception is silently ignored > > (in org.apache.coyote.Request.getCharsetFromContentType() ) and then the > > default charset is used (in > > org.apache.catalina.connector.InputBuffer.checkConverter()). > > > > According to Servlet 3.1 specification, 3.11, the default charset should > be > > used if the client does not specify a charset in the request. > > > > Is this change of behavior in 8.5.15 intentional? > > It is unintentional. Please create an issue for this in Bugzilla. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Issue when the Content-Type request header specifies invalid charset
Hello, Prior to Tomcat 8.5.15 if the Content-Type request header specifies an invalid charset, then the HttpServletRequest.getReader() throws a UnsupportedEncodingException (from its javadoc:it should throw such an exception if the character set encoding used is not supported and the text cannot be decoded). However, in Tomcat 8.5.15, with change https://github.com/apache/tomcat85/commit/18e70aff0fd3e9195d2bf01e445c49ea9fd44d0b this exception is silently ignored (in org.apache.coyote.Request.getCharsetFromContentType() ) and then the default charset is used (in org.apache.catalina.connector.InputBuffer.checkConverter()). According to Servlet 3.1 specification, 3.11, the default charset should be used if the client does not specify a charset in the request. Is this change of behavior in 8.5.15 intentional? Regards, Lazar
Re: Jsp character encoding configuration
Thanks Mark! Here it is: https://bz.apache.org/bugzilla/show_bug.cgi?id=60769 On Tue, Feb 21, 2017 at 9:49 PM, Mark Thomas <ma...@apache.org> wrote: > On 18/02/2017 16:32, Lazar Kirchev wrote: > > I noticed something else strange. If in an jspx file I declare one and > > the same encoding (in my case Windows-1252) in both the XML prolog and > > the page directive pageEncoding property, on Tomcat 8.5.11 I get the > > error message: > > "Page-encoding specified in XML prolog (UTF-8) is different from that > > specified in page directive (WINDOWS-1252)", while on older Tomcat 8.5 I > > get no error and the page is displayed. > > > > I attach the sample1.war with this jspx file. > > Please open a bugzilla issue for this. > > I suspect that there is a BoM present and that is causing the behaviour > you see. > > Mark > > > > Kind regards, > > Lazar > > > > On Sat, Feb 18, 2017 at 4:48 PM, Lazar Kirchev <lazar.kirc...@gmail.com > > <mailto:lazar.kirc...@gmail.com>> wrote: > > > > Hello, > > > > According to the JSP 2.3 spec, > > section 3.3.4 (Declaring page encodings): > > "It is also a translation-time error to name different encodings in > > the prolog / text declaration of the document in XML syntax and in a > > JSP configuration element matching the document. It is legal to name > > the same encoding through multiple mechanisms." > > > > and in > > > > section 4.1.2 (XML Syntax): > > "It is a translation-time error to name different encodings in two > > or more of the following: the XML prolog / text declaration of a JSP > > document, the pageEncoding attribute of the page directive of the > > JSP document, and in a JSP configuration element whose URL pattern > > matches the document." > > > > However, on Tomcat 8.5.11 the attached sample.war, which declares > > UTF-8 encoding through a configuration element and Windows-1252 with > > the XML prolog of a .jspx file, does not throw an exception and > > displays the jspx. But it works as expected for the index.jsp, which > > declares again a different encoding from the one declared through > > JSP configuration in web.xml. > > > > On older versions of Tomcat 8.5 both requests fail as expected. This > > is probably due to change > > > > https://github.com/apache/tomcat85/commit/ > a03c5755a6fa2d9daa43abe357628f475230fdb2 > > <https://github.com/apache/tomcat85/commit/ > a03c5755a6fa2d9daa43abe357628f475230fdb2> > > ? > > > > > > Regards, > > > > Lazar > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Jsp character encoding configuration
I noticed something else strange. If in an jspx file I declare one and the same encoding (in my case Windows-1252) in both the XML prolog and the page directive pageEncoding property, on Tomcat 8.5.11 I get the error message: "Page-encoding specified in XML prolog (UTF-8) is different from that specified in page directive (WINDOWS-1252)", while on older Tomcat 8.5 I get no error and the page is displayed. I attach the sample1.war with this jspx file. Kind regards, Lazar On Sat, Feb 18, 2017 at 4:48 PM, Lazar Kirchev <lazar.kirc...@gmail.com> wrote: > Hello, > > According to the JSP 2.3 spec, > section 3.3.4 (Declaring page encodings): > "It is also a translation-time error to name different encodings in the > prolog / text declaration of the document in XML syntax and in a JSP > configuration element matching the document. It is legal to name the same > encoding through multiple mechanisms." > > and in > > section 4.1.2 (XML Syntax): > "It is a translation-time error to name different encodings in two or more > of the following: the XML prolog / text declaration of a JSP document, the > pageEncoding attribute of the page directive of the JSP document, and in a > JSP configuration element whose URL pattern matches the document." > > However, on Tomcat 8.5.11 the attached sample.war, which declares UTF-8 > encoding through a configuration element and Windows-1252 with the XML > prolog of a .jspx file, does not throw an exception and displays the jspx. > But it works as expected for the index.jsp, which declares again a > different encoding from the one declared through JSP configuration in > web.xml. > > On older versions of Tomcat 8.5 both requests fail as expected. This is > probably due to change > > https://github.com/apache/tomcat85/commit/a03c5755a6fa2d9daa43abe357628f > 475230fdb2 ? > > > Regards, > > Lazar > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Jsp character encoding configuration
Hello, According to the JSP 2.3 spec, section 3.3.4 (Declaring page encodings): "It is also a translation-time error to name different encodings in the prolog / text declaration of the document in XML syntax and in a JSP configuration element matching the document. It is legal to name the same encoding through multiple mechanisms." and in section 4.1.2 (XML Syntax): "It is a translation-time error to name different encodings in two or more of the following: the XML prolog / text declaration of a JSP document, the pageEncoding attribute of the page directive of the JSP document, and in a JSP configuration element whose URL pattern matches the document." However, on Tomcat 8.5.11 the attached sample.war, which declares UTF-8 encoding through a configuration element and Windows-1252 with the XML prolog of a .jspx file, does not throw an exception and displays the jspx. But it works as expected for the index.jsp, which declares again a different encoding from the one declared through JSP configuration in web.xml. On older versions of Tomcat 8.5 both requests fail as expected. This is probably due to change https://github.com/apache/tomcat85/commit/a03c5755a6fa2d9daa43abe357628f475230fdb2 ? Regards, Lazar - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Configuring certificate for ssl support on Tomcat 8.5
Hello, According to Tomcat 8.5 documentation [1] when JSSE is used if the key alias is not specified through the attribute certificateKeyAlias of Certificate entry, then "... the first key read from the keystore will be used...". However, when the property is not specified Tomcat tries to use a default key alias (which is "tomcat"). At least I got (on Tomcat 8.5.4) java.io.IOException: Alias name tomcat does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:213) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:101) Is this the intended behavior? Specifying explicitly certificateKeyAlias works like a charm. [1] https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_Certificate
Re: Increased memory consumption due to url encoding
Hello Christopher, I tried with 32 MB and even 24 MB heap and the CPU usage and response time remained the almost the same (the difference is negligible) as with 1 GB heap. The cumulative allocated memory for the HeapByteBuffer remains about 400 MB, but of course the frequency of GCs is increased. Regards, Lazar On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 8/9/16 8:40 AM, Lazar Kirchev wrote: > > Hello! When handling requests which make use of request dispatcher, > > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This > > seems to come from the encoding of the path introduced with this > > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ > > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023 > hrev= > > > > > 1741024 > > 5 requests to a very simple servlet which only gets a request > > dispatcher for some path lead to allocation of about 400 MB. > > However, after a GC they are freed and this actually does not > > influence CPU or response time. Has anybody noticed this effect and > > what do you think about it? > > What happens if you set the heap size very low (e.g. 32MiB) and run > the same test? Does the memory usage grow to 400MiB, or does the > request performance start to degrade? > > I'm curious if you are just seeing the effect of the GC doing its job > correctly. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7 > lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ > ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA > MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl > mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq > fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr > wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y > Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz > 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6 > ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz > 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz > m0ntWlqyXwr6EbmRjbFE > =FTq+ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Increased memory consumption due to url encoding
Hello! When handling requests which make use of request dispatcher, Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This seems to come from the encoding of the path introduced with this change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ apache/catalina/core/ApplicationContext.java?r1=1741024=1741023= 1741024 5 requests to a very simple servlet which only gets a request dispatcher for some path lead to allocation of about 400 MB. However, after a GC they are freed and this actually does not influence CPU or response time. Has anybody noticed this effect and what do you think about it? Kind regards, Lazar
Using ServletContainerInitializer for 2.5 applications
Hello, In servlet 3.0 specification ServletContainerInitilizer class is defined to allow programatic addition of servlet/filters/listeners. I am using a ServletContextInitializer to add a ServletContextListener to the ServletContext. I use Tomcat 7.0.25. This works fine if the web.xml major version is 3, but if it is 2 it does not work. I checked the org.apache.catalina.startup.ContextConfig code and it seems that ServletContainerInitializers are added to the StandardContext only if the major version is = 3 (in an if-statement in the webConfig() method). Could you help me with this? Regards, Lazar
Re: Using ServletContainerInitializer for 2.5 applications
I want the ServletContainerInitializer to be called for all applications I deploy, not only with web.xml version 3.0, but also with lower version. Is this possible? On Wed, Apr 11, 2012 at 3:17 PM, Mikolaj Rydzewski m...@ceti.pl wrote: On 11.04.2012 14:10, Lazar Kirchev wrote: In servlet 3.0 specification ServletContainerInitilizer class is defined to allow programatic addition of servlet/filters/listeners. I am using a ServletContextInitializer to add a ServletContextListener to the ServletContext. I use Tomcat 7.0.25. This works fine if the web.xml major version is 3, but if it is 2 it does not work. I checked the org.apache.catalina.startup.**ContextConfig code and it seems that ServletContainerInitializers are added to the StandardContext only if the major version is = 3 (in an if-statement in the webConfig() method). Could you help me with this? Help with what? What is the problem? -- Mikolaj Rydzewski m...@ceti.pl --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using ServletContainerInitializer for 2.5 applications
On Wed, Apr 11, 2012 at 3:54 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Lazar Kirchev [mailto:lazar.kirc...@gmail.com] Subject: Re: Using ServletContainerInitializer for 2.5 applications I want the ServletContainerInitializer to be called for all applications I deploy, not only with web.xml version 3.0, but also with lower version. Is this possible? Simply put, no. ServletContainerInitializer doesn't exist in the 2.5 spec and thus cannot be used with webapps written to that version of the spec. - Chuck Actually I have created a shared library, which extends the web container. This library provides an implementation of the ServletContainerInitializer interface according to the servlet 3.0 specification - chapter 8.2.4, Shared libraries / runtimes pluggability. I expect the ServletContainerInitializer to be called for each web application, deployed in the web container. However, it gets called only if the version of the web.xml of the deployed application is 3.0. Is this according to the specification? After all, the library extends the container itself and not a particular application. THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
