On 10.03.2020 15:44, Martin Grigorov wrote:
On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz <
-----BEGIN PGP SIGNED MESSAGE-----
On 3/10/20 04:43, Martin Grigorov wrote:
We can define custom address like "loopback" for which Tomcat will
bind on both "127.0.0.1" and "::1" depending on the values of
java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I
am not sure whether it is worth it
This is kind of an interesting suggestion, as would maybe supporting
"all" as an alias for both 0.0.0.0 and :: together (the old default
behavior, which is no longer possible with a single <Connector>).
Are there any examples of these kinds of things in other products, or
does everyone just manually define two separate connector-like entities?
httpd just does:
Which is pretty simple. Tomcat's <Connector> configuration is a lot
more verbose and so repeating it is doubly so.
Another option is to make "address" attribute multi valued, e.g.
My 2 cent :
Since the changes were necessary, have been made and are presumably there to stay, and
since this seems to have caused a lot of confusion with a lot of sysadmins, mainly among
the ones which had a working front-end/back-end configuration, which suddenly stopped
working when they made a minor version upgrade. And since even so, it seems that when the
change was made, there was quite an underestimate of the side-effects and the impact this
would have in the practical reality out there, should there not be a separate addition to
the documentation, explaining this AJP Connector and its settings "from the ground up",
starting with the fact that currently, it is basically insecure if used on an open network
(and that this was not its original purpose).
(At least that's my sysadmin-level understanding of what I've read here so far).
And when talking about changing some Connector attributes, maybe a review should be made
first, downwards as well as upwards :
- downwards : ultimately a Connector represents a socket (or more than one ?), at the OS
TCP/IP stack level. Some information from that OS-level socket presumably "filters up"
through whatever layers there can be between it, and the container level and the Java
servlets running inside that container. Is that information liklely to be used at the
application level, and would proposed changes be neutral in that respect ?
- upwards : it seems from the accumulated discussions here, that (for example) to
implement some of the changes/improvement, users (sysadmins) may have to go as far as
duplicating the whole Connector tag, to implement the "listen only on localhost" feature
(but, that this depends both on the underlying OS and on the in-between layer between that
OS and the Connector). And, if some application software currently "interrogates" the
Connector to find out about its IP address (or the IP address of the client connected to
it), what answer would it get if the "address" attribute would become multi-value ?
/Could/ it even get such an answer, if the underlying socket is not one, but two ?
I don't know the answer to the above questions, and I don't even know whether they really
are valid questions. But again, I look at this from a sysadmin configurator point of
view, without necessarily a deep understanding on the Java finery underlying all this, and
I'm quite confused and worried that I could inadvertently break some user application and
not really understand why.
And maybe another underlying question : is it really unthinkable to have an AJP connection
capable of running under SSL ? (I mean directly, not under some external setup like
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org