Re: HTTP2 with WebSockets
I could add a second port but then I’d have to change how the load balancer works to add even more magic there than I already have... not sure http2 is worth that effort. On Wed, Feb 6, 2019 at 6:54 PM John Larsen wrote: > I am interested in this too. Basically we've had to set another port in > which the app can access tomcat for websockets directly. We've not been > able to get this to work over httpd. > John > > > On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman > wrote: > > > Is it possible for tomcat to run with HTTP2 and WebSockets on the same > > connector? I have tried configuring it myself and looked for examples > > without success. > > > > Thanks! > > Jesse > > >
Re: HTTP2 with WebSockets
I am interested in this too. Basically we've had to set another port in which the app can access tomcat for websockets directly. We've not been able to get this to work over httpd. John On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman wrote: > Is it possible for tomcat to run with HTTP2 and WebSockets on the same > connector? I have tried configuring it myself and looked for examples > without success. > > Thanks! > Jesse >
Re: Tomcat patch management and patching best practices
Thats a really good question. We've simply replaced the entire tomcat installation and then rerun auto config. Be nice if apache provided patches. John On Wed, Feb 6, 2019 at 7:39 PM Murtaza Doctor wrote: > Dear Support, > > We request your help/advice for the Tomcat Patch Management. We have > installed Tomcat server to host an application which is internally used in > our organisation. We donot have any current process/procedure to patch > Tomcat. So we are looking for your advice on this. > > Please address my below queries: > > 1) What is the best procedure/practice to keep Tomcat up-to-date with > patches? > > 2) How frequently does Tomcat releases patches/updates? If patches are > available, please advice the link to access the patches and its details > (including steps to apply it) > > 3) Are separate patches released for security vulnerabilities fixed and bug > fixed in Tomcat application server? > > Kindly advice. Your suggestion will help us in building our internal > processes. Thanks. > > Kind Regards, > Murtaza Doctor. >
Tomcat patch management and patching best practices
Dear Support, We request your help/advice for the Tomcat Patch Management. We have installed Tomcat server to host an application which is internally used in our organisation. We donot have any current process/procedure to patch Tomcat. So we are looking for your advice on this. Please address my below queries: 1) What is the best procedure/practice to keep Tomcat up-to-date with patches? 2) How frequently does Tomcat releases patches/updates? If patches are available, please advice the link to access the patches and its details (including steps to apply it) 3) Are separate patches released for security vulnerabilities fixed and bug fixed in Tomcat application server? Kindly advice. Your suggestion will help us in building our internal processes. Thanks. Kind Regards, Murtaza Doctor.
HTTP2 with WebSockets
Is it possible for tomcat to run with HTTP2 and WebSockets on the same connector? I have tried configuring it myself and looked for examples without success. Thanks! Jesse
Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7
On 06/02/2019 17:21, James H. H. Lampert wrote: > Thanks. I do have some follow up questions > > On 2/6/19, 1:04 AM, Mark Thomas wrote: >> On the TLS Connector: >> >> sslEnabledProtocols="TLSv1.1,TLSv1.2" > > Ok. So the active connector we currently have for this particular > installation (which has multiple IP addresses, hence the "address" > clause) is: >> > protocol="org.apache.coyote.http11.Http11Protocol" address="REDACTED" >> maxThreads="150" SSLEnabled="true" scheme="https" >> secure="true" >> keystoreFile="REDACTED" keyAlias="REDACTED" >> >> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" >> clientAuth="false" sslProtocol="TLS" /> > > So I can just add the sslEnabledProtcols clause to the end of this? Yes. >>> 17369 - HTTP Security Header Not Detected. >> It looks like this one: >> >> https://community.qualys.com/thread/17369-http-security-header-not-detected >> > > I concur on that, but how do I add the headers it's looking for? Depending on what exactly what is missing, the built-in HttpHeaderSecurityFilter may be able to help. If that can't met the requirement you'll probably need to write a custom Filter - or get the app devs to add one. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
response sent before request
Hello, I have a tomcat 8.5.20 installation that handle many applications. When calling one of the URLs of a specific application, sometimes I get a 500 http error. Please note that this it does not happens always. The connector uses SSL, so I setup wireshark and decrypted the traffic. Finally I found this: an SSL stream that displays the response before the request, i.e., this is what is shown as decrypted: *** HTTP/1.1 500 Content-Type: text/plain Content-Length: 57 Date: Wed, 06 Feb 2019 15:23:46 GMT Connection: close The call failed on the server; see server log for detailsPOST /lnuiprod/gwtui/persist HTTP/1.1 Host: srclnprod.mydomain.tld:8445 Connection: keep-alive Content-Length: 18118 X-GWT-Module-Base: https://srclnprod.mydomain.tld:8445/lnuiprod/gwtui X-GWT-Permutation: 8E921 Origin: https://srclnprod.mydomain.tld:8445 User-Agent: Mozilla/.36 Content-Type: text/x-gwt-rpc; charset=UTF-8 Accept: */* Referer: https://srclnprod.mydomain.tld:8445/lnui/servlet/login Accept-Encoding: gzip, deflate, br Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7 Cookie: JSESSIONID=B.2F£ 7|1|14|http... (body continues until the end of the stream) *** I see the request in the valve log. I see an exception in the tomcat log from a servlet that complains about an unparseable request. The servlet that logs the message is not the one associated to the URL. I am not even sure it is from the same context. So, I wonder, what instructs tomcat to start parsing a request? Is it the newline inbetween the header and the body? How is it possible to explain this behaviour? Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7
Thanks. I do have some follow up questions On 2/6/19, 1:04 AM, Mark Thomas wrote: On the TLS Connector: sslEnabledProtocols="TLSv1.1,TLSv1.2" Ok. So the active connector we currently have for this particular installation (which has multiple IP addresses, hence the "address" clause) is: So I can just add the sslEnabledProtcols clause to the end of this? 17369 - HTTP Security Header Not Detected. It looks like this one: https://community.qualys.com/thread/17369-http-security-header-not-detected I concur on that, but how do I add the headers it's looking for? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Number of tomcat downloads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igal, On 2/5/19 14:59, Igal Sapir wrote: > Chris, > > On Tue, Feb 5, 2019 at 6:32 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Igal, >> >> On 2/4/19 23:52, Igal Sapir wrote: >>> On that note, should we add Google Analytics to the new >>> site? >> >> Hard pass, thank you very much. >> > > I didn't necessarily mean that it has to be GA, even though I > mentioned it by name as it's the most popular tool out there - it > was more like saying "Xerox" instead of "Copier", or "Kleenex" > instead of "Tissue". I've gotten great mileage out of log-file analyzers. No need for javascript in pages :) > It can be any tool, including the one you suggested in the other > email, but anyway, as Mark pointed out this decision might be made > at a higher level. In general, PMCs are left to make their own decisions. It's possible that ASF will say "absolutely no GA" but they would never say "you must use GA". My strong position for Tomcat PMC would be "absolutely no GA", regardless of what ASF says. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxbA74ACgkQHPApP6U8 pFhYcxAAvIK823QQk2LaX1ZnZPolxbcOvRQivTbF9zSdmVMi+dMM76I0fn+wNhp8 wOq+xbShQsEovZr9tzykhH0/krUilOkdY/ldW/OCc20kpkWinEVTtUNF4ldq+AqB 6lA76MJIRyuNa8x295LKHIigXgSqwiy4iDHkFr/5o/5sW74y0i1cX8n/Ac5yMtpt bZLOxiGpvaYxUbR1Pm9XnBZUFRcX5If74NdjqV/XstSViKuDHtYqQ/x/nYXTiOZC TkPaAW3n/69ionTpKTosDTweklTm0q22XYkhOH8UspChpuwHAK/SHLKDmOZZ4QdK oe6qnJ/SCa7cVX1sQaNsYhZcYMe8Jm7rK+SRdnTWst+cPCD3b0qlMaTmULNY5e8K 7Fc09yheJ76VahwDTiMR9MUNZhl3PiXGYwP8+irJdgP5WoHtNxdS8iHRqWvAylDR 2r/SS1kWUnx5NzZIfEHJuvS/z9M16sNIVCYSqwlg0o9qEgTZ82Qs3OKybyNxJ5H6 pn4Rw8Y1ZOlK/3FXawGAd90qJWU5LHLK1hb8P4ReI5YHsyq66i8+Z9olahae5BDp 7zd3PfzAmMx90tkpuv8mqC7Y4qlu/EopCrFIR8yS11hwVIcLGv7URScuuUnWHlHa u2cFtPvAKDdz8FHBC+S6GgRcekYK5p4gehL8Ti5uAApRhnEkorw= =LVqS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark and James, On 2/6/19 04:04, Mark Thomas wrote: > On 05/02/2019 23:49, James H. H. Lampert wrote: >> We've just received word from a customer that they had two >> vulnerabilities flagged on a security scan of the box their >> Tomcat server is running on. >> >> 38628 - TLS 1.0 still supported. Ok, assuming that the box and >> the JVM can go up to a more current TLS level, and a more current >> cipher, what do I need to set? On other boxes, I've added a >> "ciphers" clause to the Connector for port 443 in the server.xml, >> but what about the TLS? > > On the TLS Connector: > > sslEnabledProtocols="TLSv1.1,TLSv1.2" Unless you will *fail* your security evaluation, you might want to keep TLSv1.0 enabled. >> 17369 - HTTP Security Header Not Detected. This, I don't get: >> what I've been able to find on this one talks about a security >> header missing on port 80; the Tomcat server (at least the one >> we're responsible for) doesn't even have 80 (or 8080) open at >> all. If I remember right, though, there are other HTTP(S) servers >> running on that box; is it perhaps one of the others? > > It looks like this one: > > https://community.qualys.com/thread/17369-http-security-header-not-det ected > > While that page talks about port 80, it would apply equally to > any HTTP[S] connection. Yes, X-Frame-Options should be set regardless of the protocol. Try running nikto[1] against your site. It points out all kinds of little things and (!!) gives you better information than "header not found". - -chris [1] https://cirt.net/Nikto2 (also comes pre-installed in a Kali Linux livecd, which you can use easily from within a VM guest) -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxbAwQACgkQHPApP6U8 pFjgdxAAyKfl++O9kWtO9yYTcKtKotVMywF2tMCTcHNj3rGiVa/Jf++XtUv5Cxi1 mBcR8/FiaUUcKMbQncVD+MbcQpF1gDdw1v1pNpdHJz9opEGlNb9PFyJbh/x6BIiI m8b2wqfpootbVZ14cczzyVFkbpF5Ydw/31IYOiSN0COHvuyPrc11S2qbedvYggOz lX3h+G12jh3FFfl3SHMCeUAe0Hq5rg34K/4czsELGV0VpIzNfeacBBxrUUcsO6H5 esUPomQTGQYHsmSkF17aVxDw3Oa/Sth28CatdWGXMaOKkm7WeKbyM/UrugnJSeKE 5HnSgi5rQaRbyMGs1U3XZV0/EnndGKMdZctBWZipNzMeOxPRDA8eng0QEVZAm4QD W+mqSyGkemmxCQGYhA7Ds4uWt1hfhEGGnTBw/pGqOf1x+1G560IrJNECvEF47Zre boJoCoX9S4uY+hYprBP4ugmXgN1Ln07DxkxSxIjFRi6YaOlVzJ1P0f+rfIa0CAxO 8nxugMFHam1fJ9kvSevU5uTm/0bA4EhNKDNBRJzh0310zjfgquEw48Y+cIPQzeiy T9icqVgXVJfvsoWTjmTvwwLmQC7JAPdYFxEwI+PiNJQkcp5n3MgTV5jonLr0DSZZ uwqqxcrRs0LgQRLt1eVF7gPVOLHzGYEZNFaSUVlOpk/EQttHcWk= =D5aV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
On 06/02/2019 12:48, Jörg Schaible wrote: > Hi Mark, > > Am Mittwoch, 6. Februar 2019, 11:45:46 CET schrieb Mark Thomas: >> Exact Tomcat 8 version? >> Exact Tomcat 9 version? >> >> How is CORS configured in your application? > > the VersionLoggerListener entries from the catalina.log files: > > this is the machine with Tomcat 8: > == %< == > - Server version:Apache Tomcat/8.0.41 > - Server built: Jan 18 2017 22:19:39 UTC > - Server Version:Apache Tomcat/9.0.14 > - Server built: Dec 6 2018 21:13:53 UTC You have almost 2 years of bug fixes between those versions. Looks like you've hit the fixes for these bugs: https://bz.apache.org/bugzilla/show_bug.cgi?id=62676 https://bz.apache.org/bugzilla/show_bug.cgi?id=62761 https://bz.apache.org/bugzilla/show_bug.cgi?id=62343 (CVE-2018-8014) > The CORS-Settings from the web.xml: > > == %< == > > CorsFilter > org.apache.catalina.filters.CorsFilter > > cors.exposedHeaders > Set-Cookie > > > > CorsFilter > /* > > == %< == You need to set cors.allowed.origin to an appropriate value. See: http://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Invalid URL characters via AJP
On 06/02/2019 14:05, George Stanchev wrote: > In light of recent changes around allowing and subsequent relaxation of the > invalid characters handling in TC, I just noticed that TC behind IIS (via JK > connector/AJP) happily accepts ";<> etc while the HTTP connector rejects > them. Is this how the AJP connector it is supposed to work? Is the assumption > that the fronting service should be the line of defence? > The expectation is that the web server follows the HTTP specification. I'd expect a web server to respond with a 400 to any invalid URI. The defenses in the JK Connector are designed to protect against valid but malicious URIs. Generally, directory traversal attacks and similar attempts to bypass security constraints. As far as I recall, there aren't explicit checks for URI validity. I'll note that ; is a valid character in a URI while "<> do indeed need to be escaped. As an aside, this page may be useful for folks testing around this: https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Invalid URL characters via AJP
In light of recent changes around allowing and subsequent relaxation of the invalid characters handling in TC, I just noticed that TC behind IIS (via JK connector/AJP) happily accepts ";<> etc while the HTTP connector rejects them. Is this how the AJP connector it is supposed to work? Is the assumption that the fronting service should be the line of defence?
RE: loss of connection with mod_jk(tomcat connector)
Hi Rainer, I am not much aware about JkShmFile but it was working fine with tomcat connector 1.2.43, is anything I need to setup for more loggers because even I am also not getting the actual problem. Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Rainer Jung Sent: 06 February 2019 06:41 PM To: Tomcat Users List ; Rathore, Rajendra Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: rainer.j...@kippdata.de Hi Rajendra, Am 06.02.2019 um 12:36 schrieb Rathore, Rajendra: > Hi Mark, > > I am stuck and due to below issue unable to update to latest tomcat > connector, can you please share your finding, let me know if you need > anything from my side, I also raise issue > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63075data=02%7C01%7Crarathore%40ptc.com%7C1a09aaa2eae847b573eb08d68c349039%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C636850554720305577sdata=6u4FOXO5xbYRAJ2GFXE8zwNOIZ2MyNuVtuphdD6xur0%3Dreserved=0 > but there is no progress on it. as Mark already wrote, your mod_jk log file shows, that many of your tomcat instances are down. You have configured a load balancer with 9 members, listening on localhost ports 8010-8018, but of these 9 tomcat instances only the one listening on port 8010 was up. So some requests work, because they were forwarded coincidentally to the working port, others fail, because they were forwarded to one of the 8 ports were nothing is listening and even their failover failed, because when only one out of 9 ports work, chances are very high, that the failover also hits a port where nothing listens. mod_jk remembers the failing workers (ports) for some time and will not retry to use them, but as I wrote in the ticket, you have a broken JkShmFile, so mod_jk balancers can not correctly work. Fix that problem first and make sure your ports are actually listening. Regards, Rainer > -Original Message- > From: Rathore, Rajendra > Sent: 17 January 2019 10:33 AM > To: Tomcat Users List > Subject: RE: loss of connection with mod_jk(tomcat connector) > > External email from: > users-return-266670-rarathore=ptc@tomcat.apache.org > > Hi Mark, > > We configure multiple tomcat and based on the configuration start > other tomcat, since one tomcat running fine but after some time it > will stop communicating, this problem we face from Tomcat Connector > 1.2.46 version onwards, for 1.2.43 it works fine, please let me know > if I need to enable extra loggers that will help out to understand the > problem better, > > Thanks and Regards, > Rajendra Rathore > 9922701491 > > -Original Message- > From: Mark Thomas > Sent: 17 January 2019 05:05 AM > To: Tomcat Users List > Subject: Re: loss of connection with mod_jk(tomcat connector) > > External email from: > users-return-29-rarathore=ptc@tomcat.apache.org > > On 16/01/2019 12:26, Rathore, Rajendra wrote: >> Hi Team, >> >> >> >> we are using Apache Http server with basic authentication, when we >> try to send some request to apache for authentication it will fail >> with >> 401 error and when we check the JK Status, >> >> we found that status was not proper means instead of 'OK' state it >> was 'Awaiting..'. We are facing this issue with tomcat connector >> 1.2.46, it worked with 1.2.43. I attached our log files for your >> reference, please let me know if you need anything else. > > Logs show the Tomcat instances aren't listening on the configured host/ports. > > Mark
Re: loss of connection with mod_jk(tomcat connector)
Hi Rajendra, Am 06.02.2019 um 12:36 schrieb Rathore, Rajendra: Hi Mark, I am stuck and due to below issue unable to update to latest tomcat connector, can you please share your finding, let me know if you need anything from my side, I also raise issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63075 but there is no progress on it. as Mark already wrote, your mod_jk log file shows, that many of your tomcat instances are down. You have configured a load balancer with 9 members, listening on localhost ports 8010-8018, but of these 9 tomcat instances only the one listening on port 8010 was up. So some requests work, because they were forwarded coincidentally to the working port, others fail, because they were forwarded to one of the 8 ports were nothing is listening and even their failover failed, because when only one out of 9 ports work, chances are very high, that the failover also hits a port where nothing listens. mod_jk remembers the failing workers (ports) for some time and will not retry to use them, but as I wrote in the ticket, you have a broken JkShmFile, so mod_jk balancers can not correctly work. Fix that problem first and make sure your ports are actually listening. Regards, Rainer -Original Message- From: Rathore, Rajendra Sent: 17 January 2019 10:33 AM To: Tomcat Users List Subject: RE: loss of connection with mod_jk(tomcat connector) External email from: users-return-266670-rarathore=ptc@tomcat.apache.org Hi Mark, We configure multiple tomcat and based on the configuration start other tomcat, since one tomcat running fine but after some time it will stop communicating, this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 it works fine, please let me know if I need to enable extra loggers that will help out to understand the problem better, Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Mark Thomas Sent: 17 January 2019 05:05 AM To: Tomcat Users List Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: users-return-29-rarathore=ptc@tomcat.apache.org On 16/01/2019 12:26, Rathore, Rajendra wrote: Hi Team, we are using Apache Http server with basic authentication, when we try to send some request to apache for authentication it will fail with 401 error and when we check the JK Status, we found that status was not proper means instead of 'OK' state it was 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, it worked with 1.2.43. I attached our log files for your reference, please let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Receiving 403 with Tomcat 9, works with Tomcat 8
Hi Mark, Am Mittwoch, 6. Februar 2019, 11:45:46 CET schrieb Mark Thomas: > Exact Tomcat 8 version? > Exact Tomcat 9 version? > > How is CORS configured in your application? the VersionLoggerListener entries from the catalina.log files: this is the machine with Tomcat 8: == %< == - Server version:Apache Tomcat/8.0.41 - Server built: Jan 18 2017 22:19:39 UTC - Server number: 8.0.41.0 - OS Name: Windows Server 2012 R2 - OS Version:6.3 - Architecture: amd64 - Java Home: D:\Programme\Java - JVM Version: 1.8.0_121-b13 - JVM Vendor:Oracle Corporation - CATALINA_BASE: D:\Programme\Tomcat - CATALINA_HOME: D:\Programme\Tomcat - Command line argument: -Dcatalina.home=D:\Programme\Tomcat - Command line argument: -Dcatalina.base=D:\Programme\Tomcat - Command line argument: -Djava.endorsed.dirs=D:\Programme\Tomcat\endorsed - Command line argument: -Djava.io.tmpdir=D:\Programme\Tomcat\temp - Command line argument: - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Command line argument: -Djava.util.logging.config.file=D: \Programme\Tomcat\conf\logging.properties - Command line argument: exit - Command line argument: -Xms5120m - Command line argument: -Xmx30720m == %< == this is the machine with Tomcat 9: == %< == - Server Version:Apache Tomcat/9.0.14 - Server built: Dec 6 2018 21:13:53 UTC - Server version number: 9.0.14.0 - OS Name: Windows Server 2012 R2 - OS Version:6.3 - Architektur: amd64 - Java Home: D:\Programme\OpenJDK11 - JVM Version: 11.0.2+9 - JVM Hersteller:Oracle Corporation - CATALINA_BASE: D:\Programme\Tomcat - CATALINA_HOME: D:\Programme\Tomcat - Command line argument: -Dcatalina.home=D:\Programme\Tomcat - Command line argument: -Dcatalina.base=D:\Programme\Tomcat - Command line argument: -Djava.io.tmpdir=D:\Programme\Tomcat\temp - Command line argument: - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Command line argument: -Djava.util.logging.config.file=D: \Programme\Tomcat\conf\logging.properties - Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED - Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED - Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED - Command line argument: exit - Command line argument: abort - Command line argument: -Xms5120m - Command line argument: -Xmx30720m == %< == The CORS-Settings from the web.xml: == %< == CorsFilter org.apache.catalina.filters.CorsFilter cors.exposedHeaders Set-Cookie CorsFilter /* == %< == Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: loss of connection with mod_jk(tomcat connector)
Hi Mark, I am stuck and due to below issue unable to update to latest tomcat connector, can you please share your finding, let me know if you need anything from my side, I also raise issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63075 but there is no progress on it. Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Rathore, Rajendra Sent: 17 January 2019 10:33 AM To: Tomcat Users List Subject: RE: loss of connection with mod_jk(tomcat connector) External email from: users-return-266670-rarathore=ptc@tomcat.apache.org Hi Mark, We configure multiple tomcat and based on the configuration start other tomcat, since one tomcat running fine but after some time it will stop communicating, this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 it works fine, please let me know if I need to enable extra loggers that will help out to understand the problem better, Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: Mark Thomas Sent: 17 January 2019 05:05 AM To: Tomcat Users List Subject: Re: loss of connection with mod_jk(tomcat connector) External email from: users-return-29-rarathore=ptc@tomcat.apache.org On 16/01/2019 12:26, Rathore, Rajendra wrote: > Hi Team, > > > > we are using Apache Http server with basic authentication, when we try > to send some request to apache for authentication it will fail with > 401 error and when we check the JK Status, > > we found that status was not proper means instead of 'OK' state it was > 'Awaiting..'. We are facing this issue with tomcat connector 1.2.46, > it worked with 1.2.43. I attached our log files for your reference, > please let me know if you need anything else. Logs show the Tomcat instances aren't listening on the configured host/ports. 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: Receiving 403 with Tomcat 9, works with Tomcat 8
Exact Tomcat 8 version? Exact Tomcat 9 version? How is CORS configured in your application? Mark On 06/02/2019 10:36, Jörg Schaible wrote: > Hi, > > we have a strange symptom after an upgrade from Tomcat 8 to Tomcat 9, because > we get a 403 for a call that works flawlessly with the previous version. > > Let's describe the scenario: We have a customer with a Wordpress application > hosted on an Apache server. Some pages perform XMLHttpRequests to load and > embed HTML snippets from other sources. One such source is our > (load-balanced) > web application running on Tomcat. These requests are using GET or POST, > depending on the situation. However, after the switch from Tomcat 8 to Tomcat > 9, the GET request is replied by Tomcat with 403. And the only trace is an > entry in the access_log. However, if we use the request URL directly in the > browser, the call succeeds. > > We are using a vanilla installation of Tomcat. The load-balancer will map the > HTTPS calls on port 443 to HTTP on port 8080. The only modification to the > configuration is in catalina.properties, where we skip the jar scanning: > > - tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* > > And we have some additional attributes at the connector in the server.xml: > >port="8080" protocol="HTTP/1.1" > connectionTimeout="2" > redirectPort="8443" > maxThreads="1000" > acceptCount="400" > allowHostHeaderMismatch="true" /> > > Originally we suspected the "allowHostHeaderMismatch" attribute, because it > changed its default from true in Tomcat 8 to false in Tomcat 9, but it had no > effect on the communication > > If we look at the network analysis in the browser, we have following request > parameters (example): > > == %< > GET https://tomcat.test-server.local/app/service?param=1 > > The HTTP request header contains: > - Host: tomcat.test-server.local > - Origin: https://www.test-server.local > - Referrer: https://www.test-server.local/ > - DNT: 1 > > The HTTP response header contains: > - Access-Control-Allow-Credentials: true > - Access-Control-Allow-Origin: https://www.test-server.local > - Cache-Control: no-cache > - Content-Type: text/xml;charset=UTF-8 > - Server: Apache-Coyote/1.1 > - Transfer-Encoding: chunked > == %< > > We found the switched default for "allowHostHeaderMismatch" by chance. Are > there other parameters in the Tomcat configuration that are new or have > changed > their default, which may influence this communication? > > What's the best way to analyze this on the Tomcat side? Are there any special > logger settings to get more info about this 403? > > Regards, > Jörg > > > > - > 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
Receiving 403 with Tomcat 9, works with Tomcat 8
Hi, we have a strange symptom after an upgrade from Tomcat 8 to Tomcat 9, because we get a 403 for a call that works flawlessly with the previous version. Let's describe the scenario: We have a customer with a Wordpress application hosted on an Apache server. Some pages perform XMLHttpRequests to load and embed HTML snippets from other sources. One such source is our (load-balanced) web application running on Tomcat. These requests are using GET or POST, depending on the situation. However, after the switch from Tomcat 8 to Tomcat 9, the GET request is replied by Tomcat with 403. And the only trace is an entry in the access_log. However, if we use the request URL directly in the browser, the call succeeds. We are using a vanilla installation of Tomcat. The load-balancer will map the HTTPS calls on port 443 to HTTP on port 8080. The only modification to the configuration is in catalina.properties, where we skip the jar scanning: - tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* And we have some additional attributes at the connector in the server.xml: Originally we suspected the "allowHostHeaderMismatch" attribute, because it changed its default from true in Tomcat 8 to false in Tomcat 9, but it had no effect on the communication If we look at the network analysis in the browser, we have following request parameters (example): == %< GET https://tomcat.test-server.local/app/service?param=1 The HTTP request header contains: - Host: tomcat.test-server.local - Origin: https://www.test-server.local - Referrer: https://www.test-server.local/ - DNT: 1 The HTTP response header contains: - Access-Control-Allow-Credentials: true - Access-Control-Allow-Origin: https://www.test-server.local - Cache-Control: no-cache - Content-Type: text/xml;charset=UTF-8 - Server: Apache-Coyote/1.1 - Transfer-Encoding: chunked == %< We found the switched default for "allowHostHeaderMismatch" by chance. Are there other parameters in the Tomcat configuration that are new or have changed their default, which may influence this communication? What's the best way to analyze this on the Tomcat side? Are there any special logger settings to get more info about this 403? Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7
On 05/02/2019 23:49, James H. H. Lampert wrote: > We've just received word from a customer that they had two > vulnerabilities flagged on a security scan of the box their Tomcat > server is running on. > > 38628 - TLS 1.0 still supported. > Ok, assuming that the box and the JVM can go up to a more current TLS > level, and a more current cipher, what do I need to set? On other boxes, > I've added a "ciphers" clause to the Connector for port 443 in the > server.xml, but what about the TLS? On the TLS Connector: sslEnabledProtocols="TLSv1.1,TLSv1.2" > 17369 - HTTP Security Header Not Detected. > This, I don't get: what I've been able to find on this one talks about a > security header missing on port 80; the Tomcat server (at least the one > we're responsible for) doesn't even have 80 (or 8080) open at all. If I > remember right, though, there are other HTTP(S) servers running on that > box; is it perhaps one of the others? It looks like this one: https://community.qualys.com/thread/17369-http-security-header-not-detected While that page talks about port 80, it would apply equally to any HTTP[S] connection. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
