Re: Mod_JK vs Mod_Proxy
Jon, On 12/7/22 19:36, jonmcalexan...@wellsfargo.com.INVALID wrote: I get it and agree, but it does just add unnecessary complexity also. In my case, I find it necessary to encrypt ;) There are some reasons I can't move to mod_proxy_* yet, so it's a /necessary/ complexity for me. -chris -Original Message- From: Christopher Schultz Sent: Wednesday, December 7, 2022 4:54 PM To: Tomcat Users List ; jonmcalexan...@wellsfargo.com.INVALID Subject: Re: Mod_JK vs Mod_Proxy Jon, On 12/6/22 16:22, jonmcalexan...@wellsfargo.com.INVALID wrote: What, pray tell, is an encrypted AJP connection? Are you talking AJP over an SSH Tunnel (Stunnel)? Exactly. It's absolutely cheating, but it achieves the goal :) -chris -Original Message- From: Christopher Schultz Sent: Tuesday, December 6, 2022 3:01 PM To: users@tomcat.apache.org Subject: Re: Mod_JK vs Mod_Proxy Jon, On 12/6/22 12:36, jonmcalexan...@wellsfargo.com.INVALID wrote: IMHO, switching to mod_proxy, and using it over SSL, is by far better than using mod_jk or mod_ajp, primarily as mod_proxy allows for secure proxy connection, whereas mod_jk and mod_ajp aren't "secure" as they are not encrypted channels. While this is true (and supports my assertion that everyone should migrate), it doesn't preclude the use of encrypted AJP connections. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving HTTP (any version but 3 prefered) over UDP
On Fri, Dec 9, 2022 at 4:02 AM Mark Thomas wrote:
>
> On 08/12/2022 21:55, Aryeh Friedman wrote:
> > I just tried the following command to test if tomcat does in fact listen on
> > UDP:
> >
> > aryeh@sarek1024% nc -u localhost 8080
> > GET / HTTP/1.1
> >
> >
> > aryeh@sarek1024%
> >
> > Which is nice to see tomcat is listening
>
> That command doesn't do what you think it does.
>
> UDP doesn't work the way you think it does.
Please don't make assumptions about my background or about how I think
UDP works. I have designed and implemented several transport
protocols over UDP (in C not Java) see ecip.org.
The man page for nc does take the connectionless nature of UDP into
consideration. For example here is an nc session working with the
echo server on UDP port 7:
aryeh@sarek1024% nc -u 127.0.0.1 7
Hi there I am an echo
Hi there I am an echo
^C
>
> Even if Tomcat was listening for UDP packets, HTTP/3 has a completely
> different wire format to HTTP/1.1 and the above wouldn't work.
I was not attempting to use HTTP (3 or 1.1). I was only testing if I
got any response at all (or if I would get an ICMP Port Unavailable
exception/error).
For example the following code works against port 7 (UDP echo service)
but not against 8080 (my local tomcat):
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.SocketAddress;
public class UDPHttp
{
public static void main(String[] args)
throws Throwable
{
int port=7;
DatagramSocket sock=new DatagramSocket();
InetAddress addr=InetAddress.getByName("localhost");
SocketAddress sockAddr=new InetSocketAddress(addr,port);
sock.connect(sockAddr);
String msg="GET / HTTP/1.1\r\n\r\n";
byte[] buf=msg.getBytes();
DatagramPacket packet=
new DatagramPacket(buf,buf.length,sockAddr);
sock.send(packet);
byte[] out=new byte[buf.length];
packet=new DatagramPacket(out,out.length,sockAddr);
sock.receive(packet);
System.out.print(new String(out));
}
}
Yields the original value of msg
Going to 8080 gives:
Exception in thread "main" java.net.PortUnreachableException: ICMP
Port Unreachable
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
at
java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
at java.net.DatagramSocket.receive(DatagramSocket.java:812)
at UDPHttp.main(UDPHttp.java:29)
>
> Tomcat is NOT listening for UDP packets.
>
> Tomcat does not support HTTP/3 or QUIC.
Any plans in this direction?
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.1.4 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.4. Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. The notable changes compared to 10.1.2 include: - Refactor WebappLoader so it only has a runtime dependency on the migration tool for Jakarta EE if configured to use the converter as classes are loaded. - When an HTTP/2 stream was reset, the current active stream count was not reduced. If enough resets occurred on a connection, the current active stream count limit was reached and no new streams could be created on that connection. - Update to Commons Daemon 1.3.3 Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving HTTP (any version but 3 prefered) over UDP
On Fri, Dec 9, 2022 at 10:02 AM Mark Thomas wrote: > > On 08/12/2022 21:55, Aryeh Friedman wrote: > > I just tried the following command to test if tomcat does in fact listen on > > UDP: > > > > aryeh@sarek1024% nc -u localhost 8080 > > GET / HTTP/1.1 > > > > > > aryeh@sarek1024% > > > > Which is nice to see tomcat is listening > > That command doesn't do what you think it does. > > UDP doesn't work the way you think it does. > > Even if Tomcat was listening for UDP packets, HTTP/3 has a completely > different wire format to HTTP/1.1 and the above wouldn't work. > > Tomcat is NOT listening for UDP packets. > > Tomcat does not support HTTP/3 or QUIC. > > According to the roadmap: https://www.openssl.org/roadmap.html I'll look at it with 3.3, basically. Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding Compilation Steps for Tomcat version 9 on RHEL8
On 09/12/2022 07:03, Vivek Naruka (EXT-NSB) wrote: Hi, Please find attachment of Image. Images get removed before messages are posted to the list. During study on changelog.txt Tomcat projects all have changelogs but none of them are named changelog.txt in either source or published form. we could see support of OpenSSL 3.0. for tomcat native. Yes, both Tomcat Native 1.2.x and 2.0.x can be compiled with OpenSSL 3.0.0. Tomcat Native 2.0.x requires OpenSSL 3.0.x as a minimum. The current minimum OpenSSL version for Tomcat Native 1.2.x is OpenSSL 1.0.2 although that OpenSSL version is no longer supported. The supported versions of OpenSSL are generally driven not by the OpenSSL project but the versions supported by the downstream Linux distributions (we look at Debian and Ubuntu) and is tracked in this file: https://github.com/apache/tomcat-native/blob/1.2.x/native/srclib/VERSIONS It looks like we could switch to Tomcat Native 1.3.0 with minimum versions of: - OpenSSL 1.1.1 - APR 1.6.3 but there is no particular rush to do that. Please do let us know if Tomcat can provide extended support of OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after September 2023? The best I can say is that it is the current intention of the Tomcat committers that Tomcat Native 1.x will continue to support (i.e. it will be possible to build a working library with) OpenSSL 1.1.1 as long as that is the version of OpenSSL used by a supported version of Debian and/or Ubuntu. Mark -Original Message- From: Mark Thomas Sent: 07 December 2022 19:01 To: users@tomcat.apache.org Subject: Re: Regarding Compilation Steps for Tomcat version 9 on RHEL8 On 07/12/2022 09:36, Vivek Naruka (EXT-NSB) wrote: Hi, We have downloaded Tomcat version 9 "apache-tomcat-9.0.70.tar.gz" from https://tomcat.apache.org/download-90.cgi. To check the compatibility of Tomcat version 9.0 with OpenSSL 3.0, we need to compile source code of Tomcat version 9 on RHEL-8 with OpenSSL3.0. We require compilation steps to compile Tomcat source code on RHEL8. Tomcat 9.0.x does not require OpenSSL to compile. What makes you think it does? Could you please help to share the compilation steps? Try looking in the BUILDING.txt file in the root of the source tarball. The build should be fully reproducible, providing you follow the additional instructions for reproducible builds. Getting back to the OpenSSL 3.0 question. Tomcat Native, which does have a dependency on OpenSSL, is compatible with OpenSSL in both the 1.2.x and 2.0.x branches. What makes you think that it is not? You can use Tomcat Native 1.2.x or 2.0.x with Tomcat 9.0.x but if you use Tomcat Native 2.0.x, you can't use the APR/native connectors - you must use NIO or NIO2. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error setting socket options
There is no available debug logging options so you'll need to use remote debugging to figure out what is going on. https://cwiki.apache.org/confluence/display/TOMCAT/Developing#Developing-Q1 Mark On 07/12/2022 14:07, Gustavo Monti Rocha wrote: In fact I'm not setting those variables. That's why I'm not sure because I'm getting that error. On Wed, Dec 7, 2022 at 10:36 AM Mark Thomas wrote: On 07/12/2022 12:15, Gustavo Monti Rocha wrote: Hi Mark, Thanks for helping me. How can I check if my environment has valid values for JVM? If you are setting those values, the simple solution is don't set them and the JVM will use appropriate defaults for your environment. If you do want to set them (why?), then look at the docs for your JVM / platform to find acceptable values. Mark Thanks in advance. On Wed, Dec 7, 2022 at 6:21 AM Mark Thomas wrote: Make sure you have set socket.soLingerOn and socket.soLingerTime to valid values for your JVM and platform. Tomcat does not set these by default so it is something your application or Spring Boot is doing. Mark On 07/12/2022 01:47, Gustavo Monti Rocha wrote: Hello, I'm using spring boot with eureka and openfeign to communicate between services A and B. When a send a request from A to B getting: 2022-12-06 22:30:26.634 ERROR 6352 --- [o-8081-Acceptor] org.apache.tomcat.util.net.NioEndpoint : Error setting socket options java.net.SocketException: Invalid argument at java.base/sun.nio.ch.Net.setIntOption0(Native Method) ~[na:na] at java.base/sun.nio.ch.Net.setSocketOption(Net.java:455) ~[na:na] at java.base/sun.nio.ch.Net.setSocketOption(Net.java:393) ~[na:na] at java.base/sun.nio.ch .SocketChannelImpl.setOption(SocketChannelImpl.java:280) ~[na:na] at java.base/sun.nio.ch .SocketAdaptor.setIntOption(SocketAdaptor.java:247) ~[na:na] at java.base/sun.nio.ch .SocketAdaptor.setSoLinger(SocketAdaptor.java:285) ~[na:na] at org.apache.tomcat.util.net .SocketProperties.setProperties(SocketProperties.java:219) ~[tomcat-embed-core-9.0.55.jar:9.0.55] at org.apache.tomcat.util.net .NioEndpoint.setSocketOptions(NioEndpoint.java:495) ~[tomcat-embed-core-9.0.55.jar:9.0.55] at org.apache.tomcat.util.net .NioEndpoint.setSocketOptions(NioEndpoint.java:78) ~[tomcat-embed-core-9.0.55.jar:9.0.55] at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:149) ~[tomcat-embed-core-9.0.55.jar:9.0.55] at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na] I'm using Spring boot 2.5.7 and Spring Cloud 2020.0.3. java version "17.0.5" 2022-10-18 LTS Java(TM) SE Runtime Environment (build 17.0.5+9-LTS-191) Java HotSpot(TM) 64-Bit Server VM (build 17.0.5+9-LTS-191, mixed mode, sharing) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving HTTP (any version but 3 prefered) over UDP
On 08/12/2022 21:55, Aryeh Friedman wrote: I just tried the following command to test if tomcat does in fact listen on UDP: aryeh@sarek1024% nc -u localhost 8080 GET / HTTP/1.1 aryeh@sarek1024% Which is nice to see tomcat is listening That command doesn't do what you think it does. UDP doesn't work the way you think it does. Even if Tomcat was listening for UDP packets, HTTP/3 has a completely different wire format to HTTP/1.1 and the above wouldn't work. Tomcat is NOT listening for UDP packets. Tomcat does not support HTTP/3 or QUIC. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
