Re: TLS protocols and cipher suites available under JSSE?
Thanks, Mr. Schultz. I managed to find the IBM docs. At least some of the cipher suites the customer is talking about are supported all the way back to their 7.0 JVM. I've specified cipher suites by name in the connector, but I don't think I've done protocols. "TLS," according to the IBM docs, "Enables TLS v1.0 protocol (defined in RFC 2246). Accepts TLSv1 hello encapsulated in an SSLv2 format hello." Sounds like I would need to enable TLSv1.1 and TLSv1.2 explicitly. Would I change the sslProtocol clause from sslProtocol="TLS" to sslProtocol="TLSv1.1,TLSv1.2" or even sslProtocol="TLSv1.2" and specify acceptable cipher suites in the ciphers clause? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 Nio2+OpenSSL problem (very likely a bug)
On Wed, Mar 13, 2019 at 10:21 PM Mark Thomas wrote:
> On 13/03/2019 20:30, Igor T wrote:
> > Prerequisites:
> > OS: Windows Server 2012 R2
> > Java: checked on both jdk1.8.0_162 jdk1.8.0_181
> > Tomcat: windows x64 builds checked on 9.0.12, 9.0.16, 9.0.17-dev
>
> 9.0.17-dev at which point in time?
>
Since 9.0.12 and 16 do the same, I wouldn't look at that at all. Something
simple like this works in the general case, there must be something
specific here. So it's Windows, which some unspecified OpenSSL version.
Rémy
>
> Have you tested the current 9.0.17 release candidate (see dev@ for
> details)
>
> Mark
>
>
>
> > Valid SSL certificates
> > Content of file located at webapp/ROOT/1.txt: []
> > Tomcat's connector settings:
> > >
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >
> > sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
> > connectionTimeout="5000"
> > SSLEnabled="true"
> > scheme="https"
> > secure="true"
> > >
> >
> > This configuration leads to 50% of the traffic to be rejected with
> > Connection resets. First socket connects and receives the service, but
> > every second is resetted.
> >
> > Exactly this combination leads to connection resets:
> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
> >
> > Configurations that work well without connection resets:
> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> > or
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
> >
> > Java code to reproduce the connection resets (works well with any
> > other secure server):
> > (there is no resets if a variable named FIX__gotoSleepAfterHandshake =
> true)
> >
> > public class CheckConnectionResets{
> > static String host = "your-test-host";
> >
> > public static void main( String[] args ) throws
> > InterruptedException, IOException{
> >
> > SSLSocketFactory factory =
> > (SSLSocketFactory)SSLSocketFactory.getDefault();
> > int nRuns = 4;
> > int success = 0;
> > int denial = 0;
> >
> > boolean FIX__gotoSleepAfterHandshake = false;
> >
> > for( int i = 0; i < nRuns; i++ ){
> > try ( SSLSocket socket = (SSLSocket)factory.createSocket(
> > host, 443 ) ){
> >
> > if( FIX__gotoSleepAfterHandshake ){
> > socket.startHandshake();
> > Thread.sleep( 500 );
> > }
> > try ( PrintWriter out = new PrintWriter( new
> > BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) )
> > );
> > InputStream is = socket.getInputStream(); ){
> >
> > out.println( "GET /1.txt HTTP/1.1" );
> > out.println( "Host: " + host );
> > out.println( "Accept: */*" );
> > out.println();
> > out.flush();
> >
> > if( out.checkError() ){
> > System.out.println( "SSLSocketClient:
> > java.io.PrintWriter error" );
> > }
> >
> > Instant start = Instant.now();
> > /* read full response */
> > byte[] buff = new byte[ 1024 ];
> > int read = is.read( buff );
> > success++;
> > System.out.println( "success: " + success + ",
> > read " + read + " bytes for: " + start.until( Instant.now(),
> > ChronoUnit.MILLIS ) + "ms" );
> >
> > } catch ( IOException e ) {
> > denial++;
> > System.err.println( "denial: " + denial + ", " +
> > e.getMessage() );
> > }
> >
> > Sample output:
> > success: 1, read 73 bytes for: 78ms
> > denial: 1, Connection reset
> > success: 2, read 73 bytes for: 78ms
> > denial: 2, Connection reset
> >
> > The bug is stable, and always reproducible.
> >
> > -
> > 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: What is `tomcat7/common/` for?
On 13.03.19 15:01, Joel Griffith wrote: > I installed it using Ubuntu's apt-get install, so installing it again > won't do anything different. Is there a documentation page > that lists what files are supposed to be there? > That would help. I can't seem to find one. If you installed through apt-get, you're getting some packaged version that is distributed all over the file system. You can use "apt-file list tomcat8" to see what's contained and where it will appear. This is not comparable with the standard tomcat distribution. The lib directory might be on /usr/share/tomcat8/lib - in my quick check it wasn't empty. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 Nio2+OpenSSL problem (very likely a bug)
I'm testing to see if this might be an issue on a new tomcat 8.5.38 upgrade
I'm doing (using NIO2 and OpenSSL) before I promote this to our Production
environment :)
(Windows Server 2008R2, Java (javaC.exe) version is 1.8.0_191)
.. after some missteps (had to add some imports to get it to compile, and
use the -Djavax.net.ssl.trustStore, ... .trustStoreType,
..trustStorePassword args when running...
4 successes. no connection resets.
import javax.net.ss.SSLSocket;
import javax.net.ss.SSLSocketFactory
import java.io.*;
import java.time.*;
import java.time.temporal.ChronoUnit;
On Wed, Mar 13, 2019 at 3:29 PM Igor T wrote:
> Prerequisites:
> OS: Windows Server 2012 R2
> Java: checked on both jdk1.8.0_162 jdk1.8.0_181
> Tomcat: windows x64 builds checked on 9.0.12, 9.0.16, 9.0.17-dev
> Valid SSL certificates
> Content of file located at webapp/ROOT/1.txt: []
> Tomcat's connector settings:
>
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
> connectionTimeout="5000"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> >
>
> This configuration leads to 50% of the traffic to be rejected with
> Connection resets. First socket connects and receives the service, but
> every second is resetted.
>
> Exactly this combination leads to connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
>
> Configurations that work well without connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> or
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> sslImplementationName="org.apache.tomcat.util.net
> .openssl.OpenSSLImplementation"
>
> Java code to reproduce the connection resets (works well with any
> other secure server):
> (there is no resets if a variable named FIX__gotoSleepAfterHandshake =
> true)
>
> public class CheckConnectionResets{
> static String host = "your-test-host";
>
> public static void main( String[] args ) throws
> InterruptedException, IOException{
>
> SSLSocketFactory factory =
> (SSLSocketFactory)SSLSocketFactory.getDefault();
> int nRuns = 4;
> int success = 0;
> int denial = 0;
>
> boolean FIX__gotoSleepAfterHandshake = false;
>
> for( int i = 0; i < nRuns; i++ ){
> try ( SSLSocket socket = (SSLSocket)factory.createSocket(
> host, 443 ) ){
>
> if( FIX__gotoSleepAfterHandshake ){
> socket.startHandshake();
> Thread.sleep( 500 );
> }
> try ( PrintWriter out = new PrintWriter( new
> BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) )
> );
> InputStream is = socket.getInputStream(); ){
>
> out.println( "GET /1.txt HTTP/1.1" );
> out.println( "Host: " + host );
> out.println( "Accept: */*" );
> out.println();
> out.flush();
>
> if( out.checkError() ){
> System.out.println( "SSLSocketClient:
> java.io.PrintWriter error" );
> }
>
> Instant start = Instant.now();
> /* read full response */
> byte[] buff = new byte[ 1024 ];
> int read = is.read( buff );
> success++;
> System.out.println( "success: " + success + ",
> read " + read + " bytes for: " + start.until( Instant.now(),
> ChronoUnit.MILLIS ) + "ms" );
>
> } catch ( IOException e ) {
> denial++;
> System.err.println( "denial: " + denial + ", " +
> e.getMessage() );
> }
>
> Sample output:
> success: 1, read 73 bytes for: 78ms
> denial: 1, Connection reset
> success: 2, read 73 bytes for: 78ms
> denial: 2, Connection reset
>
> The bug is stable, and always reproducible.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: TLS protocols and cipher suites available under JSSE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 3/13/19 12:48 PM, James H. H. Lampert wrote: > We've got a customer who is asking about cipher suites and TLS > protocols. > > Given Tomcat 7.0.93, with the option of running it under JDK 7.0, > JDK 7.1, or JDK 8.0, can somebody point me to docs explaining what > TLS levels and cipher suites are available under the various JVMs? You should look at the docs for each version of Java: 7: https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProvi ders.html 8: https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProvi ders.html If you are using a non-standard "provider" (like one from IBM!), then you'll have to read their documentation to find out what they provide. If you are using OpenSSL, then the list of supported cipher suites will be tied to the version of OpenSSL that you are using. I would always run with the latest JDK you can tolerate. We are running Tomcat 8.5.x on OpenJDK 8 in production, but we are running OpenJDK 11 in dev/test and everything seems just fine. I don't see any reason why Tomcat 7.0.x wouldn't run on a modern JVM, and you'll get much better support for newer cipher suites. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyJe8sACgkQHPApP6U8 pFj9Pw//R2bXzuXx25L60kyzXKhOJLZroERD83EEtooadS0jIOfvs3h5G4GGuLGF MSsLEN5+DMEzAcb6+uFGcukfWLkSYkf5QL2MWJMGhm9jXQcY3TNzuURrcKhB34vg O6Gx416FPdXEBsLT7Cc20bLBlq1SvPUXMMWNJ1YGfNpi5+zDbmgcX8JsTivAx1Aw pC0b4rOAF0qfrYFhskW1alpuRlHQgRVPcFcA1MCcytO1FewCpe7gHqWeWKWOW3/Z jtCi9ChsbX6fEE6M1sD47Xqgrq2FN8eM09BXe0ZCV1dvG1H0QlJ1NkMaykbRC9DE quqPn8a7afDPjdNMO009Dx+gO/hj3I09e3rlnnq1ePu6pIRkG7Z1zR7TIuQ0A+SO utJMaTSUnbjxiU4euDo/O294dzTeJb3kfD2Z4KnR+kMAUjoJuY8K2/jtGBTGf63q o6Y6FfuwYs799c1zeYlRcaFABHV5SpgRYeVEPyVdRchv3np0WnXty6eELu0GWvYx PvTPbXNl7Il9h+4MWvK5meMy4PeLvfawgS5dAlGXrQANwBVnatbSSGrWd/h3JvvX nGQAMsWtDbOYx5P5u9c+MkkAcoLUdJq1PGNh2tVbbEVWYQBQnl57DfOHmAqOInq5 SAaa6oIg0CeKz9ymNECmwmXWFT9kM3xkLZP0xQYsUTKiSMWdQ/0= =lODH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 4 Apache Events in 2019: DC Roadshow soon [etc]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Luis, On 3/13/19 4:36 AM, Luis Rodríguez Fernández wrote: > Thanks for sharing Chris. > > BTW: I've checked the one in Berlin [1]. Do you have an idea when > the call for abstracts will be open? Sorry, I don't know anything about the event in Berlin. - -chris > El mié., 13 mar. 2019 a las 2:31, Christopher Schultz (< > ch...@christopherschultz.net>) escribió: > > All, > > On 3/6/19 09:00, Rich Bowen wrote: * Apache Roadshow DC is in [2] weeks. Register now at https://apachecon.com/usroadshowdc19/ > I'll be speaking at this event, and I'd love to meet some local > Tomcat-ers. It's $25 to attend; schedule available at > https://apachecon.com/usroadshowdc19/schedule.html > Monday, March 25th @ George Mason University, Fairfax > > Hope to see some folks there, -chris >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyJfEwACgkQHPApP6U8 pFj9Tg/8DqFGV/W9AKOHMVmZ/IeFno3t0xHrrxw+gzTvQn+sZP0HT+czHdax3k8J u4FU2Xk9SJvRuTkx9QN6Yd/IOQvHA4lpEagw2IQU8sqBUuVAVJTBHBcjCHSHgXnK uXdykt/gIjk0MkrPKsu1RQI7jIrchJqCEiNGQ1q88BiEe0WRf5CqIbHvTEQa7vKt uwGyyl3cKnK4SnWn0AwiR9hBpuqsocFwCDVrPStyhj+nbhM760MW33IZIiJSTlNY JbeIjQUvniCcOyz/1YcBZB6ebMamQ5mMSAXCcvX3CXWyin1GpepObOCh3oU8M+K8 AmLmSYPB+W5B/vffwU6/mtBGBh2l7nwREsuH+zBFiuHWdATOmPbcIiyrBv4opoUd FTRp/iXa/6Pw9KXhqWRPA+8Kan+fXGe6EwLL3hkDokB+oCIzZr7xfmf41lfIEogw 19EsOzupU4TKe99xjdWdL0xnURscxCyY63k2gizJct+im5dumZaGXl+nEGCOoV7Y ZbNPGBioc9IXcyJnz0nBSSc0VZttwB8lHHlFDCICPNkfAae8QYyBDHFkdN0jV2PX 8DhQHzyvzyjSEt7iHR637ydIZzsDcLhFhpsL/ScQqi0/kLc69R4Rfe3/dGyEMzkq bbxMwapAJKFpLqQMgZH3EqSYf+ws7SOGg+3Aoehy4UlKXgszcN8= =WIBx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What is `tomcat7/common/` for?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Joel, On 3/13/19 9:22 AM, Joel Griffith wrote: > On Tue, Mar 12, 2019 at 9:01 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Mark, > > On 3/12/19 14:39, Mark Thomas wrote: On 12/03/2019 14:42, Christopher Schultz wrote: > Joel, > > On 3/12/19 09:43, Joel Griffith wrote: >> I'm upgrading a webapp server from Tomcat 7 to Tomcat 8 >> on Ubuntu 16.04. At installation, Tomcat 7 creates a >> directory `/var/lib/tomcat7/common/`. When Tomcat 8 is >> installed, however, the `/var/lib/tomcat8/` directory it >> creates does not include a `common/` directory, and the >> deployment script complains that it isn't there. > >> build.xml:129: /var/lib/tomcat8/common/lib does not >> exist. > > This must be a deployment script that is managed by neither > the Tomcat project nor the Ubuntu package maintainers. You > will need to update it. > >> I've been searching for a day and have found exactly >> zero documentation on this, including on the official 8.0 >> migration guide ( >> https://tomcat.apache.org/migration-8.html). > > You are right; it isn't mentioned. That should be added to > the migration guide. Is is practical to try and cover changes in file system layout for distributions we don't control? > > No, but there is no mention of the classloader re-organization in > the migration guide. > > Oh, hmm. The reason it's not in there, or in the Tomcat 7 > migration guide... is because this change was made in Tomcat *6*, > and it *is* in the migration guide... for Tomcat 6. > > So, never mind. > > For some reason, I thought this change was made more recently, but > I guess not. > > Joel, it looks like your distribution was (still?) using that > directory in Tomcat 7 even thought Tomcat hasn't shipped that way > for ... a long time. I wonder if your deployment script was > accomplishing anything by touching that directory in the first > place. > > Okay, things are starting to make a bunch more sense now, thanks. > >> I think it was accomplishing something; tomcat7/common/lib/ >> contained a bunch of .jar files that looked like standard Tomcat >> installation files (tomcat7-websocket.jar, >> tomcat-catalina-7.0.68.jar, etc.). If I switch directories in >> the deployment script to tomcat8/lib/, which is empty, javac >> complains that it can't find the files to compile. It looks like >> I'm going to need to go through /usr/share/java/ and find tomcat8 >> versions of all of the .jar files in tomcat7/common/lib/ and >> symlink those to tomcat8/lib/, unless someone knows a better >> way. If you have a build script that relies on a Tomcat installation being around, you should probably fix it. Since you are using ant (as opposed to Maven), you'll want to bundle the servlet-api.jar file with your application -- and make sure that you remove the JAR file from any application artifacts that you produce -- like a WAR file. Don't build against Tomcat. Build against individual libraries. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyJemIACgkQHPApP6U8 pFiGZhAAtUM2YV/6yznw0aF/ZjLMXRiGqXSnv9GGZPmQV2vvUAtc6yv/uML/JcIA W4R5v/8YnTgvQZa4h8ngbASOTa8oA7L+G3LU40fkkJluppYBYdO4YHB8V2RMlTlh sWDD8UHOueA5I7PgRpzKgzF4UOEcwCGbaFGaXxXCcLOO+BTRUKuQbdJk9li8g9Yl o3w2FhAH01Cx9NfMlc3r/9rQ6zy3nT424Tz6epbsnenK6gCAmbCxYw61zJi9cpEI 2El/jyGpMY6p+xc1y92fHoavfNPfKQ0BFvgY85/JdU2MKzWgECpsEv2i/SzsQAzi Lfjv6FF/zSPCwwI0NU9M+SEz4PcNnosIlBWPL4fQktqjFKiM35oez94u8h3hI8h3 YLIdwGORzLLVfaO5WTw702pQabGI42AgMNvt+xsVezhj0CqVhOCBXxp+0uePIyGt KORUJKYqrcEv4Bpfyf1SGFHpPAHs4D0p4m5rxT9CPBgBIOXW9xjHWLz+lr00MEmr 4eqY34TF3Vb2odnqgn0vayQ3YeTIKh4cvmBchSUZ3VL6uZhMae8m4E4t5CSLuYlc zoXXWT1l7+kzvu4h516KxqU2UWV79PuO3uSiAD9t1ueL1LLw4dipxi2FQ27QeQIr IhMA8COmJaNmVhcEyLsAWubSBK+C/GF7qiPc7tNZjZi0tEVncXY= =wax/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 Nio2+OpenSSL problem (very likely a bug)
On 13/03/2019 20:30, Igor T wrote:
> Prerequisites:
> OS: Windows Server 2012 R2
> Java: checked on both jdk1.8.0_162 jdk1.8.0_181
> Tomcat: windows x64 builds checked on 9.0.12, 9.0.16, 9.0.17-dev
9.0.17-dev at which point in time?
Have you tested the current 9.0.17 release candidate (see dev@ for details)
Mark
> Valid SSL certificates
> Content of file located at webapp/ROOT/1.txt: []
> Tomcat's connector settings:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
> connectionTimeout="5000"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> >
>
> This configuration leads to 50% of the traffic to be rejected with
> Connection resets. First socket connects and receives the service, but
> every second is resetted.
>
> Exactly this combination leads to connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
>
> Configurations that work well without connection resets:
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> or
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
>
> Java code to reproduce the connection resets (works well with any
> other secure server):
> (there is no resets if a variable named FIX__gotoSleepAfterHandshake = true)
>
> public class CheckConnectionResets{
> static String host = "your-test-host";
>
> public static void main( String[] args ) throws
> InterruptedException, IOException{
>
> SSLSocketFactory factory =
> (SSLSocketFactory)SSLSocketFactory.getDefault();
> int nRuns = 4;
> int success = 0;
> int denial = 0;
>
> boolean FIX__gotoSleepAfterHandshake = false;
>
> for( int i = 0; i < nRuns; i++ ){
> try ( SSLSocket socket = (SSLSocket)factory.createSocket(
> host, 443 ) ){
>
> if( FIX__gotoSleepAfterHandshake ){
> socket.startHandshake();
> Thread.sleep( 500 );
> }
> try ( PrintWriter out = new PrintWriter( new
> BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) )
> );
> InputStream is = socket.getInputStream(); ){
>
> out.println( "GET /1.txt HTTP/1.1" );
> out.println( "Host: " + host );
> out.println( "Accept: */*" );
> out.println();
> out.flush();
>
> if( out.checkError() ){
> System.out.println( "SSLSocketClient:
> java.io.PrintWriter error" );
> }
>
> Instant start = Instant.now();
> /* read full response */
> byte[] buff = new byte[ 1024 ];
> int read = is.read( buff );
> success++;
> System.out.println( "success: " + success + ",
> read " + read + " bytes for: " + start.until( Instant.now(),
> ChronoUnit.MILLIS ) + "ms" );
>
> } catch ( IOException e ) {
> denial++;
> System.err.println( "denial: " + denial + ", " +
> e.getMessage() );
> }
>
> Sample output:
> success: 1, read 73 bytes for: 78ms
> denial: 1, Connection reset
> success: 2, read 73 bytes for: 78ms
> denial: 2, Connection reset
>
> The bug is stable, and always reproducible.
>
> -
> 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
Tomcat 9 Nio2+OpenSSL problem (very likely a bug)
Prerequisites:
OS: Windows Server 2012 R2
Java: checked on both jdk1.8.0_162 jdk1.8.0_181
Tomcat: windows x64 builds checked on 9.0.12, 9.0.16, 9.0.17-dev
Valid SSL certificates
Content of file located at webapp/ROOT/1.txt: []
Tomcat's connector settings:
This configuration leads to 50% of the traffic to be rejected with
Connection resets. First socket connects and receives the service, but
every second is resetted.
Exactly this combination leads to connection resets:
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
Configurations that work well without connection resets:
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
or
protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
Java code to reproduce the connection resets (works well with any
other secure server):
(there is no resets if a variable named FIX__gotoSleepAfterHandshake = true)
public class CheckConnectionResets{
static String host = "your-test-host";
public static void main( String[] args ) throws
InterruptedException, IOException{
SSLSocketFactory factory =
(SSLSocketFactory)SSLSocketFactory.getDefault();
int nRuns = 4;
int success = 0;
int denial = 0;
boolean FIX__gotoSleepAfterHandshake = false;
for( int i = 0; i < nRuns; i++ ){
try ( SSLSocket socket = (SSLSocket)factory.createSocket(
host, 443 ) ){
if( FIX__gotoSleepAfterHandshake ){
socket.startHandshake();
Thread.sleep( 500 );
}
try ( PrintWriter out = new PrintWriter( new
BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) )
);
InputStream is = socket.getInputStream(); ){
out.println( "GET /1.txt HTTP/1.1" );
out.println( "Host: " + host );
out.println( "Accept: */*" );
out.println();
out.flush();
if( out.checkError() ){
System.out.println( "SSLSocketClient:
java.io.PrintWriter error" );
}
Instant start = Instant.now();
/* read full response */
byte[] buff = new byte[ 1024 ];
int read = is.read( buff );
success++;
System.out.println( "success: " + success + ",
read " + read + " bytes for: " + start.until( Instant.now(),
ChronoUnit.MILLIS ) + "ms" );
} catch ( IOException e ) {
denial++;
System.err.println( "denial: " + denial + ", " +
e.getMessage() );
}
Sample output:
success: 1, read 73 bytes for: 78ms
denial: 1, Connection reset
success: 2, read 73 bytes for: 78ms
denial: 2, Connection reset
The bug is stable, and always reproducible.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
TLS protocols and cipher suites available under JSSE?
We've got a customer who is asking about cipher suites and TLS protocols. Given Tomcat 7.0.93, with the option of running it under JDK 7.0, JDK 7.1, or JDK 8.0, can somebody point me to docs explaining what TLS levels and cipher suites are available under the various JVMs? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
On 12/03/2019 11:45, Jäkel, Guido wrote:
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Tuesday, March 12, 2019 12:51 AM
>> To: users@tomcat.apache.org
>> Subject: Re: Followup2: Changed behaviour of Tomcat
>> Deployment/Context/Lifecycle Manager concerning symbolic links
>
>> Looking at the code in ContextConfig.fixDocBase() it looks like it
>> should be possible to switch lines 585 and 587 to use getAbsolutePath()
>> without having too much impact on any performance improvements we may
>> want to consider. That should address the regression. @Guido can you
>> confirm that please?
>
>
> Using getAbsolutePath() instead of getPath() ...
>
> File file = new File(docBase);
> if (!file.isAbsolute()) {
> -docBase = (new File(appBase, docBase)).getCanonicalPath();
> +docBase = (new File(appBase, docBase)).getAbsolutePath();
> } else {
> -docBase = file.getCanonicalPath();
> +docBase = file.getAbsolutePath();
> }
>
> also still solve the issue for me.
Good to hear. That change will be in the next 9.0.x and 8.5.x releases.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
HTTPS Invalid character found in method name. HTTP method names must be tokens.
We use selenium for our application testing. Our tests sometime fail with message "Invalid character found in method name" Error occures only on https and on on firefox 60 and internet explorer 11. Chrome, edge is OK. We use Tomcat 9.0.16, Java 11 (Adopt Open JDK 11.0.2+9) on Linux, browsers are on windows 10. We think, that there must be some error in https implementation. Log in these situations always contains request with application_data and change_cipher_spec together. But we do not understand https in these details. Thanks for any advice, Jan Vomlel javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.326 CET|SSLEngineInputRecord.java:177|Raw read ( : 17 03 03 02 74 00 00 00 00 00 00 00 01 E5 6A 79 t.jy 0010: CF D2 7A 6E 53 FB B3 97 3B 82 92 E5 7B A8 A2 EA ..znS...;... 0020: 4B B5 70 11 DE CD 7E 8C 89 08 AD 67 47 82 E1 16 K.pgG... 0030: FE 09 9A 1B F6 77 6C 67 80 0E CA 5F 55 4E 2C 2D .wlg..._UN,- 0040: D8 7B D2 71 2E 66 B4 0A DA 8D 8F 11 C6 C3 27 1B ...q.f'. 0050: 18 82 16 FE 82 7C 83 B4 3B 43 D8 81 71 9E 27 22 ;C..q.'" 0060: 76 50 EB C6 4C 11 C1 BE 01 8E B9 6A 3A 0B 6C 6F vP..L..j:.lo 0070: 01 03 74 F1 C4 90 C7 52 A6 8D 4A A8 8D AC EF A0 ..tR..J. 0080: 62 03 3D C7 6E F9 FB 39 C5 FA A6 95 FD 46 C3 51 b.=.n..9.F.Q 0090: FE 67 2E 76 44 7B B1 B6 8C 34 F4 30 EC 93 EC 1D .g.vD4.0 00A0: A1 5B 01 2B C1 DA D3 AA 88 EC E8 31 66 5F 59 CA .[.+...1f_Y. 00B0: 38 9A 53 C5 89 31 FB FF 1D 59 6D 90 08 66 DB 6C 8.S..1...Ym..f.l 00C0: 6F 4A 9C F7 3A BE D8 5D 5C 3C AA 3E 2B A5 A8 E2 oJ..:..]\<.>+... 00D0: 54 50 65 7B 9A BA 92 71 0F 7B AA 58 DF B2 AC 3E TPeq...X...> 00E0: 5B 4E A1 29 9C F2 C6 1A 5E 6B 6A 85 19 DE 1C 73 [N.)^kjs 00F0: EF D2 AC 06 48 50 8D DD 66 F7 78 87 50 00 28 26 HP..f.x.P.(& 0100: FB A7 C1 87 30 67 5B FA C8 B5 C7 41 4A 27 8E 6D 0g[AJ'.m 0110: D8 99 89 BA 32 8A 94 7F 79 2D 66 53 8D F4 6E 82 2...y-fS..n. 0120: 95 22 FF C6 E1 5E 8F B2 AA 44 25 33 14 F4 35 A1 ."...^...D%3..5. 0130: 50 84 F5 EE 5D 66 B6 AC 5A 21 72 5B 56 A3 32 07 P...]f..Z!r[V.2. 0140: 83 DF 3B A4 85 A9 3F E9 7B E6 4F 7C 73 F9 87 F5 ..;...?...O.s... 0150: 16 83 E7 24 CD 50 41 F9 43 37 CD 9D DF BE 69 E4 ...$.PA.C7i. 0160: AE 2D 81 BC 24 81 04 42 72 CE AA 76 5D 63 B4 98 .-..$..Br..v]c.. 0170: A7 B4 AB 77 F2 6C 42 4A 75 04 06 BB 19 5A 19 A5 ...w.lBJuZ.. 0180: CA E6 FE 04 61 8B 90 B4 E5 D1 B5 9D C1 49 27 5C aI'\ 0190: 41 92 DE 7B 91 AB 7D 3B 21 B9 60 A5 A2 C7 92 19 A..;!.`. 01A0: 2F 3D 82 17 FB C0 20 7A E6 79 7C B6 2E CD 50 A9 /= z.yP. 01B0: 6B 8E 7E 04 E9 32 EC 29 22 EC BB 58 C5 5F 8C A6 k2.)"..X._.. 01C0: 1D 76 CB 4E 5A 56 C7 83 C2 74 AC D5 83 70 05 80 .v.NZV...t...p.. 01D0: 19 8B E8 CF 09 98 32 D1 8B 4A 93 7B 38 F0 8A 7B ..2..J..8... 01E0: AB 88 D5 99 E3 42 76 1B C9 EB 62 94 0C F6 DA EF .Bv...b. 01F0: 9F 4D DB F0 30 CA 34 13 E7 1A 07 39 FD 92 F5 08 .M..0.49 0200: F4 E5 62 26 94 BF 3C 6A 82 4D 06 C8 96 57 12 F3 ..b&.. 0240: AE 73 B3 28 20 C7 1F 92 99 C8 55 A3 18 24 85 54 .s.( .U..$.T 0250: 19 90 1F 24 73 91 A7 3F 15 BA 83 D3 39 03 8C 89 ...$s..?9... 0260: D5 70 72 97 AF 91 4B 11 3B 72 E4 91 B5 6D BC 29 .pr...K.;r...m.) 0270: 51 C6 47 5C 73 58 84 A7 26 14 03 03 00 01 01 16 Q.G\sX..&... 0280: 03 03 00 28 00 00 00 00 00 00 00 00 17 E8 48 1B ...(..H. 0290: 07 8D 8A E9 98 CA 25 1F AD D5 02 FC 0A C9 8E 4D ..%M 02A0: F6 C6 EA 2E D6 24 8C D0 11 DA 78 D3 .$x. ) javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.326 CET|SSLEngineInputRecord.java:214|READ: TLSv1.2 application_data, length = 628 javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.326 CET|SSLEngineInputRecord.java:177|Raw read ( : 14 03 03 00 01 01 16 03 03 00 28 00 00 00 00 00 ..(. 0010: 00 00 00 17 E8 48 1B 07 8D 8A E9 98 CA 25 1F AD .H...%.. 0020: D5 02 FC 0A C9 8E 4D F6 C6 EA 2E D6 24 8C D0 11 ..M.$... 0030: DA 78 D3 .x. ) javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.326 CET|SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1 javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.326 CET|ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.327 CET|SSLEngineInputRecord.java:177|Raw read ( : 16 03 03 00 28 00 00 00 00 00 00 00 00 17 E8 48 (..H 0010: 1B 07 8D 8A E9 98 CA 25 1F AD D5 02 FC 0A C9 8E ...% 0020: 4D F6 C6 EA 2E D6 24 8C D0 11 DA 78 D3 M.$x. ) javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27 18:03:16.327 CET|SSLEngineInputRecord.java:214|READ:
Re: What is `tomcat7/common/` for?
On Wed, Mar 13, 2019 at 9:38 AM Olaf Kock wrote: > > On 13.03.19 14:22, Joel Griffith wrote: > > > I think it was accomplishing something; tomcat7/common/lib/ contained a > > > bunch of .jar files that looked like standard Tomcat installation files > > > (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.). If I switch > > > directories in the deployment script to tomcat8/lib/, which is > > empty, javac > > > complains that it can't find the files to compile. It looks like > > I'm going > > > to need to go through /usr/share/java/ and find tomcat8 versions of > > all of > > > the .jar files in tomcat7/common/lib/ and symlink those to > tomcat8/lib/, > > > unless someone knows a better way. > > If your tomcat/lib folder is empty, I suggest to download the > distribution again. It has quite a few files in there. If yours doesn't, > you can either start over, or figure out where they are instead (e.g. if > you're using your Linux distribution's packaged tomcat) > > I installed it using Ubuntu's apt-get install, so installing it again won't do anything different. Is there a documentation page that lists what files are supposed to be there? That would help. I can't seem to find one. > Olaf > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: What is `tomcat7/common/` for?
On 13.03.19 14:22, Joel Griffith wrote: > > I think it was accomplishing something; tomcat7/common/lib/ contained a > > bunch of .jar files that looked like standard Tomcat installation files > > (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.). If I switch > > directories in the deployment script to tomcat8/lib/, which is > empty, javac > > complains that it can't find the files to compile. It looks like > I'm going > > to need to go through /usr/share/java/ and find tomcat8 versions of > all of > > the .jar files in tomcat7/common/lib/ and symlink those to tomcat8/lib/, > > unless someone knows a better way. If your tomcat/lib folder is empty, I suggest to download the distribution again. It has quite a few files in there. If yours doesn't, you can either start over, or figure out where they are instead (e.g. if you're using your Linux distribution's packaged tomcat) Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What is `tomcat7/common/` for?
On Tue, Mar 12, 2019 at 9:01 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Mark, > > On 3/12/19 14:39, Mark Thomas wrote: > > On 12/03/2019 14:42, Christopher Schultz wrote: > >> Joel, > >> > >> On 3/12/19 09:43, Joel Griffith wrote: > >>> I'm upgrading a webapp server from Tomcat 7 to Tomcat 8 on > >>> Ubuntu 16.04. At installation, Tomcat 7 creates a directory > >>> `/var/lib/tomcat7/common/`. When Tomcat 8 is installed, > >>> however, the `/var/lib/tomcat8/` directory it creates does not > >>> include a `common/` directory, and the deployment script > >>> complains that it isn't there. > >> > >>> build.xml:129: /var/lib/tomcat8/common/lib does not exist. > >> > >> This must be a deployment script that is managed by neither the > >> Tomcat project nor the Ubuntu package maintainers. You will need > >> to update it. > >> > >>> I've been searching for a day and have found exactly zero > >>> documentation on this, including on the official 8.0 migration > >>> guide ( https://tomcat.apache.org/migration-8.html). > >> > >> You are right; it isn't mentioned. That should be added to the > >> migration guide. > > > > Is is practical to try and cover changes in file system layout for > > distributions we don't control? > > No, but there is no mention of the classloader re-organization in the > migration guide. > > Oh, hmm. The reason it's not in there, or in the Tomcat 7 migration > guide... is because this change was made in Tomcat *6*, and it *is* in > the migration guide... for Tomcat 6. > > So, never mind. > > For some reason, I thought this change was made more recently, but I > guess not. > > Joel, it looks like your distribution was (still?) using that > directory in Tomcat 7 even thought Tomcat hasn't shipped that way for > ... a long time. I wonder if your deployment script was accomplishing > anything by touching that directory in the first place. > > Okay, things are starting to make a bunch more sense now, thanks. I think it was accomplishing something; tomcat7/common/lib/ contained a bunch of .jar files that looked like standard Tomcat installation files (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.). If I switch directories in the deployment script to tomcat8/lib/, which is empty, javac complains that it can't find the files to compile. It looks like I'm going to need to go through /usr/share/java/ and find tomcat8 versions of all of the .jar files in tomcat7/common/lib/ and symlink those to tomcat8/lib/, unless someone knows a better way. Thanks again! > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyIVmsACgkQHPApP6U8 > pFj5AA/8COXrlLOL+LV8JM/qCvVdCWrSEzoFsBQ3yvAiHgaANPFVWaid0q5DGLiQ > J7mhzCwcT0h5ObDk1vIlTH8f+VFerlXBd6Ucio//xbQ8Gy2VXsuuNnOz42Rxuk4/ > E/LpSFljo4JUkaYs0XApxNx6yo7ZxZlK3rCvTTx2ZgVQ9SlcRIQ/m6QJkM3m153r > 1EKSTAKmp4lrsVjes4uwhA6sm/ZJDlR0qNuUAu+0g50F170qOeVJrPRQwnTcI8TE > q0zbnniw5Wlp2UcsW0gI7iLrtwu7/Bcwnjp0r9V6EA7pjagxTOMPWJxuwzF9SyZU > r+DtUNFikG7EMXl4Z9POy207B2TlBAt1FJlgkR06LxUJaJjPxdTmNhqREfeiYZGW > f+uFnrXmHK587UTMYQ4DzhEILj7ZItXyvA6fgQ2xDSoXPTdwBU7obxFZTVZwQc+D > RodvTUY1nh/xik6oFxd5BEAv5+euXR/Aag+89gPo7Qpdq5qPC05t3iHveQqf0CuE > rZIvclGKDHwMJG0QfG2UJlwU13JPxtorFc5Fh2ubPrkDypSAtw2zMb/LGeOMFDqx > h/t/i92W/j10NtMegBTvhp5lolMLTl9guRA8LhjZw15gajutdXVv2VBrlgnqhp8p > fZjNRgI6nDtXjn/OxsXypQ/6uYoJatjQ9i5JWykl42qFBa6TNHE= > =AERs > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: How to add an header field to all requests unconditionally
>-Original Message- >From: André Warnier (tomcat) [mailto:a...@ice-sa.com] >Sent: Wednesday, March 13, 2019 12:11 PM >To: users@tomcat.apache.org >Subject: Re: How to add an header field to all requests unconditionally > >The OP wants to insert a *Request* header, not a Response header. >As I recall, that is a bit more complicated, because under Tomcat the Request >is >immutable, so you have to subclass it, and add the header dynamically when the >application >issues a request.getHeaders call or so. Oh sorry, I misinterpreted that. @Thomas: By other words, you want to know something about the destination of your request. To be curious I want to know what the different Connectors are used for? Maybe there's another thing associated with the Connector that is more easy to detect for the application. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to add an header field to all requests unconditionally
Addendum : On 13.03.2019 12:03, André Warnier (tomcat) wrote: On 13.03.2019 11:44, Jäkel, Guido wrote: Dear Thomas, you may include a filter servlet into the application to modify the response header. A quick search offers e.g. https://gist.github.com/danlangford/3669475 , which states to implement a generic, configurable Response Header Filter. The OP wants to insert a *Request* header, not a Response header. As I recall, that is a bit more complicated, because under Tomcat the Request is immutable, so you have to subclass it, and add the header dynamically when the application issues a request.getHeaders call or so. You may compile this servlet independent from an existing application, therefore you may tweak even existing WARs with this. Just a note : "add a header .. to all requests coming from a given connector" Does the servlet filter know what the Connector was, through which the request was received ? And even if so, the filter would still need some configuration, in order to do that only for the Connector in question. (A httpd front-end would know, because it would be the one forwarding to that Connector specifically) Guido -Original Message- From: Thomas Meyer [mailto:tho...@m3y3r.de] Sent: Wednesday, March 13, 2019 10:43 AM To: users@tomcat.apache.org Subject: How to add an header field to all requests unconditionally Hi, what would be the easiest way to uncoditionally add an header field to all requests coming from a given connector? I searched the provided Valves but there seems to be no support for my requirment. with kind regards thomas - 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: How to add an header field to all requests unconditionally
On 13.03.2019 11:44, Jäkel, Guido wrote: Dear Thomas, you may include a filter servlet into the application to modify the response header. A quick search offers e.g. https://gist.github.com/danlangford/3669475 , which states to implement a generic, configurable Response Header Filter. You may compile this servlet independent from an existing application, therefore you may tweak even existing WARs with this. Just a note : "add a header .. to all requests coming from a given connector" Does the servlet filter know what the Connector was, through which the request was received ? And even if so, the filter would still need some configuration, in order to do that only for the Connector in question. (A httpd front-end would know, because it would be the one forwarding to that Connector specifically) Guido -Original Message- From: Thomas Meyer [mailto:tho...@m3y3r.de] Sent: Wednesday, March 13, 2019 10:43 AM To: users@tomcat.apache.org Subject: How to add an header field to all requests unconditionally Hi, what would be the easiest way to uncoditionally add an header field to all requests coming from a given connector? I searched the provided Valves but there seems to be no support for my requirment. with kind regards thomas - 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: How to add an header field to all requests unconditionally
Dear Thomas, you may include a filter servlet into the application to modify the response header. A quick search offers e.g. https://gist.github.com/danlangford/3669475 , which states to implement a generic, configurable Response Header Filter. You may compile this servlet independent from an existing application, therefore you may tweak even existing WARs with this. Guido >-Original Message- >From: Thomas Meyer [mailto:tho...@m3y3r.de] >Sent: Wednesday, March 13, 2019 10:43 AM >To: users@tomcat.apache.org >Subject: How to add an header field to all requests unconditionally > >Hi, > >what would be the easiest way to uncoditionally add an header field to >all requests coming from a given connector? >I searched the provided Valves but there seems to be no support for my >requirment. > >with kind regards >thomas > > > > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to add an header field to all requests unconditionally
On 13.03.2019 10:43, Thomas Meyer wrote: Hi, what would be the easiest way to uncoditionally add an header field to all requests coming from a given connector? Add (or use your existing) front-end Apache httpd server, with the mod_headers module ? http://httpd.apache.org/docs/2.4/mod/mod_headers.html I searched the provided Valves but there seems to be no support for my requirment. You may want to look at : http://tuckey.org/urlrewrite/ (I have not checked for your use case, but it does do many things, so maybe that also) (Note : the first suggestion above may look facetious and overkill. But it often happens that an initial simple requirement turns more complex and demanding over time, and one can do so many additional things using an Apache httpd front-end, that you may want to consider it anyway). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to add an header field to all requests unconditionally
Hi, what would be the easiest way to uncoditionally add an header field to all requests coming from a given connector? I searched the provided Valves but there seems to be no support for my requirment. with kind regards thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
>-Original Message-
>From: Johanes Soetanto [mailto:otnat...@gmail.com]
>Sent: Tuesday, March 12, 2019 9:03 PM
>To: Tomcat Users List
>Subject: Re: Followup2: Changed behaviour of Tomcat
>Deployment/Context/Lifecycle Manager concerning symbolic links
>
>Hi all,
>
>On Tue, 12 Mar. 2019, 9:45 pm Jäkel, Guido, wrote:
>
>Correct me if I'm wrong. The original reason of this discussion if the file
>extension does not end with war right? I don't see from test above that the
>links do not ends with war. Or is it because of trailing dot at the end?
Dear Johanes,
Yes, that sufficient because internal it's checked by endWith('.war'). In my
case, the filename ends with a version and a deployment node descriptor
appended. But you may append whatever you want and/or even left out the string
"war".
Guido
Re: 4 Apache Events in 2019: DC Roadshow soon [etc]
Thanks for sharing Chris. BTW: I've checked the one in Berlin [1]. Do you have an idea when the call for abstracts will be open? Thanks in advance, Luis [1] https://apachecon.com/aceu19/index.html El mié., 13 mar. 2019 a las 2:31, Christopher Schultz (< ch...@christopherschultz.net>) escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > On 3/6/19 09:00, Rich Bowen wrote: > > * Apache Roadshow DC is in [2] weeks. Register now at > > https://apachecon.com/usroadshowdc19/ > I'll be speaking at this event, and I'd love to meet some local > Tomcat-ers. It's $25 to attend; schedule available at > https://apachecon.com/usroadshowdc19/schedule.html > > > Monday, March 25th @ George Mason University, Fairfax > > Hope to see some folks there, > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyIXVoACgkQHPApP6U8 > pFhfQw/9ElIJf2BzpcHIo/fWmSwdoiQMJjRPtJ42KVob3uBbrOQ1qGXiL/Ezdjwz > 7N6koDcMX0epu7BwxD1o57ASGrvaTpUTVpmDTgQk+UZVo4qumfUxKTTMjHBuj7Cx > fbLl41V0BEaipu1BAC0cu+g6E2B3dkCB2xXk330voQdE98RYGDWPV0EZlwCBM5lu > WDiv+gwba7mJwVJh+bTT/fZ5gRBRK4MV+8O5cMQIiDoBPF0pxkj7Y9+ogk8cu9SG > 5hV1VMvWBY3fG8cvWGmSlpsfz7d2zgH3ij7y6UH1pim7OrTl6c/oUIQ+J/z5GhMV > 6yz3Rhg4IEaMHNpcFQnKI4DKQ2uKc64G1k1XJixwgnKWyQgYSPlIbqcxkMh0GGrf > kDkdzhO0vNHau4jE3dNH2tTQpsJ+obV9MHFQ8HwUpJE49qg+AAI7KLZW9BhYDX4k > QOxDTOPK9LYPcHWDc55cW6Cf8ILlMWFZW2hMITTsYgc/Y+NpB5fk9vqGOcn2RFlG > sXs4Hid9kMcZY0pFfn7P+PwcL4UUGz3fV4quW9VonlwKJswxP5jvVIYLadMQrabQ > Lnw3IniXTEh4bXy3wtUVt0Xd4l+LmoT9r04r0YA8PF7zT8Kk1BuW93imQz+DZsb1 > EnuahJrfDpfoyAjh7p54TZJQQvdqUc3L//kA+oo4X0GGDTpS4mE= > =PJsc > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
