Re: OpenSSL config for Tomcat 7

2020-02-28 Thread Jason Wee 
when you stack them, do you mean you cat those certificates into one pem file?

On Sat, Feb 29, 2020 at 8:22 AM John Beaulaurier -X (jbeaulau -
ADVANCED NETWORK INFORMATION INC at Cisco)
 wrote:
>
> Hello,
>
> We're running Tomcat 7 and need to implement SSL. We are using APR/OpenSSL, 
> but I can't get the intermediate certificates pulled in when starting Tomcat. 
> The
> server certificate is recognized and used but not the other two. I have tried 
> the following in PEM format.
>
>
>   *   Stacking them in one file and using the "SSLCertificateFile" directive
>   *   Using the "SSLCertificateFile" directive for the server cert, and 
> "SSLCertificateChainFile" directive for the CA and root cert
>
>
>  *   APR 1.4.8
>  *   Tomcat 7.0.39
>
> Any additional information needed please let me know. Any insight would be 
> greatly appreciated.
>
> Regards
> -John
>
>

-
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

2020-02-28 Thread Martin Grigorov 
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
> >>>  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 t

OpenSSL config for Tomcat 7

2020-02-28 Thread John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) 
Hello,

We're running Tomcat 7 and need to implement SSL. We are using APR/OpenSSL, but 
I can't get the intermediate certificates pulled in when starting Tomcat. The
server certificate is recognized and used but not the other two. I have tried 
the following in PEM format.


  *   Stacking them in one file and using the "SSLCertificateFile" directive
  *   Using the "SSLCertificateFile" directive for the server cert, and 
"SSLCertificateChainFile" directive for the CA and root cert


 *   APR 1.4.8
 *   Tomcat 7.0.39

Any additional information needed please let me know. Any insight would be 
greatly appreciated.

Regards
-John

Re: Client cert auth on demand

2020-02-28 Thread Martynas Jusevičius 
Yes the clients connect only directly to nginx.

So the proxy config within 2 pairs of containers is like this:

# website service; clientAuth=false
nginx:80 -> tomcat:8080
nginx:443 -> tomcat:8443

# API service; clientAuth=true
nginx-api:90 -> tomcat-api:8080
nginx-api:5443 -> tomcat-api:8443

nginx and nginx-api ports are exposed to the Docker host and that is
where the clients access them, therefore the host name the webapp sees
is localhost (as in my rewrite example).

What I'm trying to do is to fool the webapp on tomcat-api into
thinking it's being accessed on localhost:80/443 instead of
localhost:90/5443.

Absolute URIs matter in this case because they are used for direct
lookups in an RDF triplestore and RDF uses absolute URIs.


On Fri, Feb 28, 2020 at 10:59 PM Mark Thomas  wrote:
>
> On 28/02/2020 21:00, Martynas Jusevičius wrote:
> > Setting up a second container with a different port was easy enough.
> >
> > However I got stuck on the URL mapping/rewriting. Using nginx as a
> > proxy, I don't think it's possible to rewrite headers with the
> > upstream module:
> > https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> >
> > As I understand it just forwards raw traffic, so the URL rewriting
> > would have to be done on the Tomcat's side. Basically I want to
> > rewrite:
> >
> > https://localhost:5443/ => https://localhost/
> >
> > which requires rewriting the Host request header, I think.
> >
> > I was looking at the RewriteValve, but it says:
> > "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> > automatically support absolute URLs (the specific redirect flag must
> > be used to be able to specify an absolute URLs, see below) or direct
> > file serving."
> >
> > Is there a way to rewrite the hostname/port in configuration?
> > Something placed in context.xml would be ideal.
>
>
> What port is nginx listening on?
>
> What port is Tomcat listening on?
>
> I assume the client connects directly to nginx.
>
> Mark
>
>
> -
> 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: CrawlerSessionManagerValve

2020-02-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 2/28/20 13:25, Chris Cheshire wrote:
> On Fri, Feb 28, 2020 at 12:51 PM Christopher Schultz
>  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Chris and Mark,
>>
>> On 2/28/20 11:51, Mark Thomas wrote:
>>> On 28/02/2020 14:51, Chris Cheshire wrote:
 (9.0.31)

 What is the reason why the pattern isn't compiled with the
 case insensitive flag? Is it due to performance?
>>>
>>> I wrote that Valve. At least the first iteration anyway.
>>> Others improved it along the way.
>>>
>>> I honestly can't remember why I opted for [bB]bot rather than
>>> using CASE_INSENSITIVE.
>>>
>>> I do remember that the focus was on fixing an issue we (the
>>> ASF) were having with our public Jira instance at the time in
>>> that bots were generating huge numbers of sessions and, in
>>> turn, using up large amounts of memory.
>>>
>>> Looking at it with the benefit of hindsight I'd worry about: -
>>> performance - avoiding false positives
>>>
>>> There probably isn't much in it but I'd expect the current
>>> solution is the right one for both of those. Unless you have a
>>> very different UA pattern, in which case CASE_INSENSITIVE might
>>> help. But I am guessing about the performance which really
>>> isn't the done thing.
>>>
>>> If someone was to demonstrate that there was a measurable
>>> performance benefit to some realistic patterns to using
>>> CASE_INSENSITIVE then I'd support an enhancement to add an
>>> attribute to specify the flags to use when compiling the
>>> pattern.
>>
>
> More of a curiosity. I am doing some crawler checking in my webapp.
> I have an grossly repetitive regex and I was looking at this valve
> as an example to optimize things a bit. I figured if it was a CI
> check then it would negate the need for patterns like [bB].
>
> There are a couple of common patterns that it is leaving out though
> :
>
> .*[sS]p[iy]der.* .*facebookexternalhit.*
> .*(Mediapartners|Feedfetcher)-[gG]oogle.*
>
> (last one is adding 'mediapartners' to the subpattern already in
> your default regex)
>
>> You can always use the (?i) flag-enabler if you want to use
>> case-insensitive matches without changing the code.
>>
>
> +1 Did not know about this! If the flags can be specified in the
> pattern itself, then there probably isn't much need for adding
> extra attributes to the valve to achieve it.
>
> Java regex tutorial[1] does say there is a slight performance hit
> for a CI check, but it's not quantified. With processing speed
> increases, my guess is it is completely negligible per request.

Case-insensitive checks are probably pretty quick unless you start to
get into Unicode casing and locale-specific casing. Converting [A-Z]
- -> [a-z] is a simple comparison of byte value and adding the value of
('A' - 'a'). If you need to be able to convert Б to lowercase before
performing that comparison, it requires ... some additional effort.

See the documentation for the (?u) or UNICODE_CASE flag.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5ZkmwACgkQHPApP6U8
pFiKmRAAs2hm7q/kE1OU9IU5bMUVX5gjI3YAVjvn0NhNglYlYp3p11mIQ0YAB4wl
kS+kONvTXKhI0pZiEovwPizUnOkTDnAK3S6cC5NFWeK1JJfOII6MrUW4hXBQimUf
t4kNXnjXuf1/2k7kOcvAcxqx+ORCwyRemA/+U7T9IGMYeodfyIKQps3sZk6ClZvP
hC+GO2tGbR825e64IXK4ZPouoTTparsBo1j6CNe3ZlrAFLzUeqAmqwFRY0EPk7cW
AmGvX7X54AilZhzD+xrXFOUY0+V1B05qLoQYsm9j8UwSHt1a8dEMWv/Bauzwulbu
gRYnEIJeTueSSfTOO6vneAexHf5WqfG+sFgbPMsvCKvjgUywDtiiadzYE/TN1/z5
ZwkS6uvv8dpahVlzE3z12HlEGhQ0vc0Y/p+p5cwDNWTNVFS434Zxu8OplpfVREaB
fybKmCAD32ENR8KcH5fY7C25hLRPo8d1TZK9VuTSj+fhJHrStE6o0Opln6JOhjsX
rL/KPj6dma623PaH5RKSDWGtyYzI49rjLQVEA2Qw/eIh8h32Gts3DtE6uYDLDApS
6t7ELYxI0w8JCYUiFeRstmmGUYOBk0kdH0yfkP9Wc0CWInDCZvI7kI1AYRxtMdVK
Y7mrPKxOthPyyYE9LjfhnHV+LLwRk7AknxWtrRwTzzUGJhOkR24=
=cprm
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Client cert auth on demand

2020-02-28 Thread Mark Thomas 
On 28/02/2020 21:00, Martynas Jusevičius wrote:
> Setting up a second container with a different port was easy enough.
> 
> However I got stuck on the URL mapping/rewriting. Using nginx as a
> proxy, I don't think it's possible to rewrite headers with the
> upstream module:
> https://nginx.org/en/docs/http/ngx_http_upstream_module.html
> 
> As I understand it just forwards raw traffic, so the URL rewriting
> would have to be done on the Tomcat's side. Basically I want to
> rewrite:
> 
> https://localhost:5443/ => https://localhost/
> 
> which requires rewriting the Host request header, I think.
> 
> I was looking at the RewriteValve, but it says:
> "Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
> automatically support absolute URLs (the specific redirect flag must
> be used to be able to specify an absolute URLs, see below) or direct
> file serving."
> 
> Is there a way to rewrite the hostname/port in configuration?
> Something placed in context.xml would be ideal.


What port is nginx listening on?

What port is Tomcat listening on?

I assume the client connects directly to nginx.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Client cert auth on demand

2020-02-28 Thread Martynas Jusevičius 
Setting up a second container with a different port was easy enough.

However I got stuck on the URL mapping/rewriting. Using nginx as a
proxy, I don't think it's possible to rewrite headers with the
upstream module:
https://nginx.org/en/docs/http/ngx_http_upstream_module.html

As I understand it just forwards raw traffic, so the URL rewriting
would have to be done on the Tomcat's side. Basically I want to
rewrite:

https://localhost:5443/ => https://localhost/

which requires rewriting the Host request header, I think.

I was looking at the RewriteValve, but it says:
"Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
automatically support absolute URLs (the specific redirect flag must
be used to be able to specify an absolute URLs, see below) or direct
file serving."

Is there a way to rewrite the hostname/port in configuration?
Something placed in context.xml would be ideal.

On Thu, Feb 27, 2020 at 11:52 AM Martynas Jusevičius
 wrote:
>
> Tomcat is deep within the Docker image configured with a single
> connector and a single ROOT webapp, so it's easier to deploy a second
> container than to add a second connector or context :)
>
> Thanks for your help.
>
>
> On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas  wrote:
> >
> > On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > > Yes, that could be an option. Or, since we're on Docker, a second
> > > instance of the webapp on a different port would be easier.
> > >
> > > But we would need to add some URL rewriting proxy before that
> > > connector to strip that port number to make the webapp see the
> > > canonical URLs. That should be doable with nginx which we are using
> > > anyway.
> > >
> > > So essentially 2 webapps on different ports, one configured without
> > > the clientAuth for the end-users, and one with clientAuth for the API
> > > access, correct?
> >
> > It depends on what you can / want to change.
> >
> > The approach you describe should work.
> >
> > If you can change the clients, a second Connector for the same
> > Service/Engine/Host/Context is all that should be required.
> >
> > Depending on the URLs used, you might be able to deploy two versions of
> > the web application to different Contexts, remap the internal servlets
> > and still have clients see the same URLs. In that case you could move
> > the client auth requirement to the web application.
> >
> > There are quite a few options. It really comes down to want you can
> > control, and what is easiest for you to change.
> >
> > Mark
> >
> >
> > >
> > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas  wrote:
> > >>
> > >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > >>> Hi list,
> > >>>
> > >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > >>> end-user facing webapp but also as a REST API which authenticates
> > >>> using client certificates. The same URLs serve both purposes, however
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >>> In the browser however it prompts a certificate selection (if there
> > >>> are any client certs). This would not be a problem if the webapp would
> > >>> not be user-facing, but since it is the certificate prompt can be
> > >>> confusing to many users and increase our bounce rate.
> > >>>
> > >>> I'm looking for some workaround that would not require changing the
> > >>> whole design. For example asking for the client cert only when a
> > >>> certain flag is set, such as a query param or request header.
> > >>> Or somehow not asking for it but still accepting it :) But I guess
> > >>> that's not how TLS works...
> > >>>
> > >>> Any ideas? Thanks.
> > >>
> > >> Can you configure a separate connector on a different port for the shell
> > >> scripts to use?
> > >>
> > >> Mark
> > >>
> > >> -
> > >> 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
> > >
> >
> >
> > -
> > 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: CrawlerSessionManagerValve

2020-02-28 Thread Chris Cheshire 
On Fri, Feb 28, 2020 at 12:51 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris and Mark,
>
> On 2/28/20 11:51, Mark Thomas wrote:
> > On 28/02/2020 14:51, Chris Cheshire wrote:
> >> (9.0.31)
> >>
> >> What is the reason why the pattern isn't compiled with the case
> >> insensitive flag? Is it due to performance?
> >
> > I wrote that Valve. At least the first iteration anyway. Others
> > improved it along the way.
> >
> > I honestly can't remember why I opted for [bB]bot rather than
> > using CASE_INSENSITIVE.
> >
> > I do remember that the focus was on fixing an issue we (the ASF)
> > were having with our public Jira instance at the time in that bots
> > were generating huge numbers of sessions and, in turn, using up
> > large amounts of memory.
> >
> > Looking at it with the benefit of hindsight I'd worry about: -
> > performance - avoiding false positives
> >
> > There probably isn't much in it but I'd expect the current solution
> > is the right one for both of those. Unless you have a very
> > different UA pattern, in which case CASE_INSENSITIVE might help.
> > But I am guessing about the performance which really isn't the done
> > thing.
> >
> > If someone was to demonstrate that there was a measurable
> > performance benefit to some realistic patterns to using
> > CASE_INSENSITIVE then I'd support an enhancement to add an
> > attribute to specify the flags to use when compiling the pattern.
>

More of a curiosity. I am doing some crawler checking in my webapp. I
have an grossly repetitive regex and I was looking at this valve as an
example to optimize things a bit. I figured if it was a CI check then
it would negate the need for patterns like [bB].

There are a couple of common patterns that it is leaving out though :

.*[sS]p[iy]der.*
.*facebookexternalhit.*
.*(Mediapartners|Feedfetcher)-[gG]oogle.*

(last one is adding 'mediapartners' to the subpattern already in your
default regex)

> You can always use the (?i) flag-enabler if you want to use
> case-insensitive matches without changing the code.
>

+1 Did not know about this! If the flags can be specified in the
pattern itself, then there probably isn't much need for adding extra
attributes to the valve to achieve it.

Java regex tutorial[1] does say there is a slight performance hit for
a CI check, but it's not quantified. With processing speed increases,
my guess is it is completely negligible per request.

Chris

[1] https://docs.oracle.com/javase/tutorial/essential/regex/pattern.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CrawlerSessionManagerValve

2020-02-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris and Mark,

On 2/28/20 11:51, Mark Thomas wrote:
> On 28/02/2020 14:51, Chris Cheshire wrote:
>> (9.0.31)
>>
>> What is the reason why the pattern isn't compiled with the case
>> insensitive flag? Is it due to performance?
>
> I wrote that Valve. At least the first iteration anyway. Others
> improved it along the way.
>
> I honestly can't remember why I opted for [bB]bot rather than
> using CASE_INSENSITIVE.
>
> I do remember that the focus was on fixing an issue we (the ASF)
> were having with our public Jira instance at the time in that bots
> were generating huge numbers of sessions and, in turn, using up
> large amounts of memory.
>
> Looking at it with the benefit of hindsight I'd worry about: -
> performance - avoiding false positives
>
> There probably isn't much in it but I'd expect the current solution
> is the right one for both of those. Unless you have a very
> different UA pattern, in which case CASE_INSENSITIVE might help.
> But I am guessing about the performance which really isn't the done
> thing.
>
> If someone was to demonstrate that there was a measurable
> performance benefit to some realistic patterns to using
> CASE_INSENSITIVE then I'd support an enhancement to add an
> attribute to specify the flags to use when compiling the pattern.

You can always use the (?i) flag-enabler if you want to use
case-insensitive matches without changing the code.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5ZUyAACgkQHPApP6U8
pFgAERAAtsF3fKvMs/nWMM+wEPBJPOs+81Sd+LoWkWaTc2dtxXlqmi+VVtK0HsOj
RKO6WDVHD39Bzlf5PP8gi0Wjb9VgteyUl8A+Iz8TXC++iC2oUfQ8j3E3jX9zSWgV
fxgrNmGtvJ4g6Rh+/sjLDjIBJ0dAyfJtYn3D+XpJgd1d9F/YNgHjXNWhHQ2pjG5j
b0hVCcdvSHC+VMt7bGA1KdHFeVm6FqM6m8JVnPmlOBnAmOw0NSioMymEphvXiLfX
2Qy+RYe5J/LJwoJkYV5CYDuqLKBYci+t+vaOAfVt3a+RVs2aJGH86YbWjMLQ89o3
r5AC6K3RXMdKoyKRthwQ2/+uL9UoytFyikydImSREO+L9xpvaOruFZI8mSjeHHIt
RwpbaOZntiCmzfaKEgBJNtnlcPg54VgW49RJ8WdUS0z2q3+nc9oJ3VB15bjUSgLb
uH/0ak8GfjTyO8rnYgG1hXcQWby2iSdfMZvxNjU/SPL8qwN9UB3TIIfjTsoUAgcy
xkbaGKkdh/ChMXles4QRVBNXUK1MFCWKhgfW2a8oHuBRmguk36ORJ1f6lO1gEz2j
GVl7g8MhFTKcCx9DE8axd2Ywt6VPI5f/8RdTFGbJ/taO7p69YnoOD8fgqKzs1kcc
4oYtU1ZlN2y08wz9owkUuYFjUWT9spLkHX8tE3DwbkdZdo3QfUs=
=s2f5
-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

2020-02-28 Thread Lazar Kirchev 
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/
>>> > >> 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

Re: CrawlerSessionManagerValve

2020-02-28 Thread Mark Thomas 
On 28/02/2020 14:51, Chris Cheshire wrote:
> (9.0.31)
> 
> What is the reason why the pattern isn't compiled with the case
> insensitive flag? Is it due to performance?

I wrote that Valve. At least the first iteration anyway. Others improved
it along the way.

I honestly can't remember why I opted for [bB]bot rather than using
CASE_INSENSITIVE.

I do remember that the focus was on fixing an issue we (the ASF) were
having with our public Jira instance at the time in that bots were
generating huge numbers of sessions and, in turn, using up large amounts
of memory.

Looking at it with the benefit of hindsight I'd worry about:
- performance
- avoiding false positives

There probably isn't much in it but I'd expect the current solution is
the right one for both of those. Unless you have a very different UA
pattern, in which case CASE_INSENSITIVE might help. But I am guessing
about the performance which really isn't the done thing.

If someone was to demonstrate that there was a measurable performance
benefit to some realistic patterns to using CASE_INSENSITIVE then I'd
support an enhancement to add an attribute to specify the flags to use
when compiling the pattern.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: issue faced in tomcat 8.5.51

2020-02-28 Thread tomcat/perl 

On 28.02.2020 15:11, calder wrote:

On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra  wrote:


Hi Team,

I am using below configuration in server.xml for tomcat



but I got below exception in start up time



< snip >





Caused by: java.lang.IllegalArgumentException:

The AJP Connector is configured with secretRequired="true" but the secret

attribute is either null or "". This combination is not valid






Please let me know what should I put to fix the issue, it will be very

helpful for me.



Sure, here you go : look carefully at the on-line documentation, in
http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations

Note, for information : these attributes and values have *changed in 8.5.51*, compared to 
previous tomcat revisions.



-
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

2020-02-28 Thread Lazar Kirchev 
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/
>> > > 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
>> >>> thi

CrawlerSessionManagerValve

2020-02-28 Thread Chris Cheshire 
(9.0.31)

What is the reason why the pattern isn't compiled with the case
insensitive flag? Is it due to performance?

Chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: issue faced in tomcat 8.5.51

2020-02-28 Thread calder 
On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra  wrote:

> Hi Team,
>
> I am using below configuration in server.xml for tomcat
>
>  secretRequired="false" secure="false"  address="127.0.0.1"
>tomcatAuthentication="false" enableLookups="false"
> maxPostSize="-1" maxSavePostSize="8388608" maxParameterCount="-1"
>useBodyEncodingForURI="true" URIEncoding="UTF-8"
> backlog="100" packetSize="8192"
>maxThreads="320" minSpareThreads="8"/>
>
> but I got below exception in start up time
>

< snip >

>

Caused by: java.lang.IllegalArgumentException:

The AJP Connector is configured with secretRequired="true" but the secret
> attribute is either null or "". This combination is not valid
>





Please let me know what should I put to fix the issue, it will be very
> helpful for me.
>
> I am stuck because of the above issue, we are using Apache and tomcat for
> serving the request.
>
> Let me know if anything else required from my side.
>

Re: cookie configurations for Tomcat 7

2020-02-28 Thread Lazar Kirchev 
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/
> >  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 introdu

issue faced in tomcat 8.5.51

2020-02-28 Thread Rathore, Rajendra 
Hi Team,

I am using below configuration in server.xml for tomcat



but I got below exception in start up time

2020-02-27 17:59:57,524 ERROR [Servlet engine main] 
org.apache.catalina.core.StandardService  - Failed to start connector 
[Connector[AJP/1.3-8010]]
org.apache.catalina.LifecycleException: Protocol handler start failed
   at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
   at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at com.ptc.tomcat.embedded.Bootstrap.start(Bootstrap.java:495)
   at com.ptc.tomcat.embedded.Bootstrap.start(Bootstrap.java:439)
   at 
com.ptc.tomcat.embedded.Bootstrap.lambda$new$0(Bootstrap.java:167)
   at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured 
with secretRequired="true" but the secret attribute is either null or "". This 
combination is not valid.
   at 
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
   at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
   ... 19 more


Please let me know what should I put to fix the issue, it will be very helpful 
for me.

I am stuck because of the above issue, we are using Apache and tomcat for 
serving the request.

Let me know if anything else required from my side.


Thanks and Regards,
Rajendra Rathore
9922701491

Re: Problem compiling jsps after switching to 8.5.51

2020-02-28 Thread Mark Thomas 
On 28/02/2020 10:57, Marek Neumann wrote:
> After going to the latest 8.5 release we have problems with jasper compiling 
> jsps:
> 
> [WARNING] org.apache.jasper.JasperException: javax.el.ELException: Unable to 
> find ExpressionFactory of type: # Licensed to the Apache Software Foundation 
> (ASF) under one or more
> 
> We are using jetty-jspc-maven-plugin in version 9.4.24 to compile. There was 
> a change to service loading: 
> https://github.com/apache/tomcat/commit/ef13eb8fd9962432d244a7aad9cd85998d4cd3b9#diff-305be246f9d4a2068624785e76ee06efR1
> 
> Somehow the apache expression implementation 
> (org.apache.el.ExpressionFactoryImpl) cannot be found anymore. Is there 
> anything that need to be changed in our setup? Going back to 8.5.50 for 
> jasper-el solves the problem.

This is likely the same as:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64153

Waiting for 8.5.52 is probably the simplest solution.

You should be OK to compile with 8.5.50 but run with 8.5.51 if you need to.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Problem compiling jsps after switching to 8.5.51

2020-02-28 Thread Marek Neumann 
After going to the latest 8.5 release we have problems with jasper compiling 
jsps:

[WARNING] org.apache.jasper.JasperException: javax.el.ELException: Unable to 
find ExpressionFactory of type: # Licensed to the Apache Software Foundation 
(ASF) under one or more

We are using jetty-jspc-maven-plugin in version 9.4.24 to compile. There was a 
change to service loading: 
https://github.com/apache/tomcat/commit/ef13eb8fd9962432d244a7aad9cd85998d4cd3b9#diff-305be246f9d4a2068624785e76ee06efR1

Somehow the apache expression implementation 
(org.apache.el.ExpressionFactoryImpl) cannot be found anymore. Is there 
anything that need to be changed in our setup? Going back to 8.5.50 for 
jasper-el solves the problem.

Thanks for help,
Marek