Am 2020-12-09 um 14:36 schrieb Graham Leggett:
On 01 Dec 2020, at 14:09, Mark Thomas <ma...@apache.org> wrote:
I also object to the removal of OpenSSL code, for the same reason.
It isn't being removed. The APR/Native library will be retained along
with OpenSSL support for the NIO and NIO2.
I expect the scope of the APR/Native library for Tomcat 10.1.x onwards
will be reduced to just those native methods required to interact with
OpenSSL which may mean removal of the APR dependency. If we can use
OpenSSL without any native code of our own (e.g. via project Panama or
similar) then better still.
I don’t see the logic here.
If the use of native code is a risk, then I expect to see use of openssl and
any other API brought in by Panama avoided for the same reason?
We are in the middle of a global pandemic. Our users do not have the resources
to suddenly divert to reengineering what is to them a perfectly working system,
to replace what exists with something else that just works differently.
Upgrading to Tomcat 10 already requires significant re-engineering work
due to the java package change for all the specification APIs.
Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with
OpenSSL requires a change of three/four characters in one configuration
file. We have deliberately made it very easy to switch between connectors.
No-one is being forced to upgrade.
Atlassian forced me to upgrade.
This is the core of the problem - gone are the days when Tomcat was just a
simple server that people downloaded and used to make bespoke web services and
could write code any way they liked. Now Tomcat is part of other systems, who
in turn have other support horizons unrelated to this project.
The AJP deprecation is a problem. For those unaware of what AJP did, AJP
allowed a proxy server and Tomcat to be “glued” together as it they were one
server, and not two discrete entities. The proxy configuration - that’s SSL,
authn and authz - was passed transparently across to Tomcat which behaved as if
Tomcat itself had performed the SSL, authn and authz. Sure, if you have a
bespoke web service and the budget you can make hack changes to compensate. If
your Tomcat is being provided by a vendor, or if you’re under financial strain
due a pandemic, then no - you have a sudden very unwelcome headache.
The closest RFC compliant solution to this problem is JSON Web Tokens (JWT),
which allows data to be passed across both securely and in an RFC compliant way
over HTTP. Tomcat should have fixed this problem first, and then deprecated AJP
with the clear notice “use this alternative in future”.
I don't see how JWTs relate here?
But for the sake of support, especially with the addition of UDS which
is very very nice, it makes logically sense to split both and maybe
leave APR only under the hood of Tomcat with a few committers supporting
it while a recommendation would be to try on NIO(2) and have APR as a
viable alternative? Java native support for UDS will not arrive that
soon, especially not in 8 or 11.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
