Am 27.06.2018 um 21:49 schrieb Igal Sapir:
On 6/27/2018 11:28 AM, Rémy Maucherat wrote:
On Wed, Jun 27, 2018 at 7:09 PM Mark Thomas <ma...@apache.org> wrote:
On 27/06/18 17:50, Rainer Jung wrote:
Since encryption would be most of the most useful features and IMHO we
won't get there, I suggest we discuss deprecation and EOL dates for AJP
- meaning mod_jk and AJP connectors.
+1
There's no need to rush, but there could be a clear statement, that no
feature improvements will be done and users should plan for moving to
mod_proxy_http (or other http/https) clients.
I think it would be better to invest time in improving mod_proxy where
it still might lack. For instance adding custom headers to transport
communication info from the proxy to the backend like AJP does and
which
could be noticed by our Tomcat http connectors and/or support for the
PROXY protocol.
+1
So what do people think about:
1) adding a statement to the mod_jk docs, that we don't plan any
feature
enhancements and suggest users to migrate to mod_proxy_http and the TC
HTTP connectors (but what about IIS? I think there are reverse proxy
modules there as well?)
I believe there is, but we should investigate it a little first to see
what the feature set is. I have a full set of current Windows OSes plus
IIS VMs. I'm happy to look into this aspect.
2) Adding a similar statement to the connector docs for AJP to TC 7-9.
+1, with the above caveat.
3) Deprecating AJP in TC 9 and removing in TC 10
That was sooner than I was expecting. I guess it comes down to what the
timescale is for Tomcat 10 and that depends on Jakarta EE. I think I'd
like to wait until we have a clearer picture of the Jakarta EE roadmap
before deciding. If Tomcat 10 was far enough in the future (and assuming
IIS has a reasonable set of features) then I'd be OK with that.
How far is "far enough" and what "reasonable" means I'm still thinking
about ;)
+1 for everything, it doesn't seem significant enhancements will
happen so
this makes perfect sense.
Rémy
+1 from me as well.
My main issue with AJP is that you can not add custom headers, which are
many times desired (e.g. I often set a custom header of a Request-ID on
the proxy server and then log it in the Proxy server, Tomcat, and the
Servlet. That allows me to trace a request when troubleshooting issues).
Not trying to deviate, but any header set with mod_headers RequestHeader
directive should automatically be forwarded (I use it often eg. for
request IDs). Alternatively one can use JkEnvVar to forward httpd
request environment variables as request attributes. No idea about IIS
though.
When I try to migrate clients from AJP to HTTP Proxy they usually tell
me that they chose AJP because the data is transferred in binary format
vs. the HTTP text so they believe that it is faster. I make the argument
that for such small requests the encoding/decoding to/from binary adds
more overhead than the gained benefit of the data format.
I do not expect the marshalling/unmarshalling to make a big difference
between AJP and HTTP. Typically the CPU cycles used for a request are
dominated by application stuff. Everything else is so small, that it
only costs noticeable resources if you are doing many thousand requests
per second.
Not arguing against you, since you are +1, just adding my thoughts.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
