Re: [OT] Objection to the deprecation of the tomcat-native/APR connector

[Christopher Schultz <ch...@christopherschultz.net>]

Graham,

On 12/9/20 08:36, Graham Leggett wrote:
> [Downstream use of Tomcat] 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.
Downstream consumers of Tomcat are welcome to re-integrate APR into 
their products if they choose to do so. If you are a paying customer and 
need a feature, it's up to your vendor (e.g. Atlassian) to either 
support you or lose your business.

> 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.
Really, the only "hack" required is to enable the RemoteIPValve[1] and 
SSLValve[2]. I consider having to separately-compile and install mod_jk 
to be a "hack" at the web server level. httpd ships with mod_proxy 
already built-in.

I personally am very interested in deprecating and removing AJP from 
Tomcat for a number of reasons (lack of features, unnecessary additional 
complexity) but I continue to use AJP in production while I work to 
ensure that mod_proxy_* have feature parity with mod_jk (to wit, 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64338, 
https://bz.apache.org/bugzilla/show_bug.cgi?id=53667, and possibly others).

If mod_proxy_http + Tomcat can't get the job done, let's actively work 
to fix those so they CAN get the job done.

> 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'm not sure what you mean, here. While I suppose JWT can be used for 
just about anything anyone wants, it is typically used to package 
authentication and authorization information into a format that the user 
can be trusted to handle, rather than something that is maintained 
exclusively server-side (e.g. by passing that information from httpd -> 
Tomcat without involving the client).

Why would you involve the client here when you can pass anything you 
want directly to Tomcat via (RFC-compliant, I might add) HTTP headers?

(I notice that the "tomcatAuthentication" <Connector> attribute is 
AJP-only. That would be an obvious improvement to add that to either 
another Valve or incorporate into one of the existing proxy-support 
Valves in Tomcat.)

-chris

[1] 
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve
[2] http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#SSL_Valve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org