Hi Konstantin,
Am 19.06.26 um 13:36 schrieb Konstantin Kolinko:
пн, 15 июн. 2026 г. в 12:02, Rainer Jung <[email protected]>:
Picking up the date suggested by Mark I propose to announce the EOL date
2027-06-30 for the worker types ajp12 and ajp14 in Tomcat connectors aka
mod_jk aka ISAPI redirector.
Reason for ajp12: The sources say it is deprecated at least for a decade
now, the docs say it's obsolete. I never saw it in use or remember any
question raised about it.
Reason for ajp14: it was always experimental. I never saw it in use or
remember any question raised about it.
Some source code files or types and functions could be dropped as well
at the EOL date, because they are only used by ajp12 or ajp14 (eg.
jk_sockbuf annd jk_sb_* for ajp12, jk_md5 for ajp14).
Setting EOL date for ajp12:
[ ] Yes, I agree with EOL 2027-06-30
[ ] No, I don't agree with any EOL
[x] I strongly prefer EOL date .......... instead
Setting EOL date for ajp14:
[ ] Yes, I agree with EOL 2027-06-30
[ ] No, I don't agree with any EOL
[x] I strongly prefer EOL date .......... instead
My strong preference is for NOW as the EOL date.
Where are those protocols documented?
At the specifications page in the wiki I have only a link to v 1.3.
https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-AJP
No clue about v1.2.
Is 1.4 covered by https://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html
What other side of a server-server connection implements these
protocols? I think that Tomcat does not implement them.
Good point. I looked a bit at (very) old downloads. It seems:
- ajp12 was removed in TC 4
- ajp14 was remove in TC 6
I had not thought about that side of the protocol use before. Although
it is technically possible, it seems no other backends support AJP 12 or
14 at all. Jetty seems to have removed AJP (even 13) in Jetty 9 many
years ago, and JBoss (I guess) used Tomcat as a web container at the
time Tomcat removed it. On the proxy side, it seems the nginx ajp
modules also only supports AJP 13.
Are they disabled by default?
If we have no clue and cannot really provide technical support, it
would be fair to declare it publicly.
If not now,
an alternative may be to put our EOL message into the release
announcement, and delete the code with the next release (that might be
a month or a year away), but I see no real benefit for the delay.
That's probably a good plan. Adding test to the next release, stating
that it is the last release which supports the long obsolete protocols
ajp12 and ajp14. At least Mark also said he would agree on any earlier
date and I am also totally fine with that.
I guess we can have a release not to far in the future, containing
Chris's cleanups, but maybe not ones, that are too risky in order not to
break that release.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
