Re: ColdFusion10 custom mod_jk difference
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Doug, On 4/8/14, 3:44 PM, Doug Strick wrote: > We're moving from ColdFusion8 to CF10 where I work and ran into a > strange issue. We tried using mod_jk-1.2.39 and it compiled fine. > We were able to get the communication working, but ran into strange > errors like below. Adobe provides their own customized version of > mod_jk which appears to be built from 1.2.32. When I compiled > their version from the source they provide our errors went away. I > downloaded the source from here if anyone's interested: > http://helpx.adobe.com/coldfusion/kb/rhel-connector-configuration.html. Do > you know what the difference is between the ASF version and theirs? IMHO it should work if you use the ASF version directly. I can't see a reason for them to have their own (separate) source. > I'd like to avoid using their custom version as I don't know how it > will play if other non-ColdFusion based apps want to use AJP in the > future. The tech you use for your web application is not relevant: AJP is just a binary HTTP-forwarding protocol. Theoretically, there should be nothing about the web application that would require something specific (and extra) to be supported by CF or anything else. > Does anyone have any recommendations on how I might be able to > figure out what was changed? I'm not a developer so I don't know > much at the code level. You could use "diff -r" against the Adobe code in one directory and the ASF code in another. I'm not going to download it all and pour through it, but you can easily do so. Make sure to use a diff argument that ignores whitespace. > [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug] > ajp_send_request::jk_ajp_common.c (1713): (cfusion) request body to > send 0 - request body to resend 0 [Fri Apr 04 15:22:49 2014] > [9753:139964571830064] [debug] > ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received > from ajp13 pos=0 len=14 max=65536 [Fri Apr 04 15:22:49 2014] > [9753:139964571830064] [debug] > ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0F > 00 0A 2F 69 6E 64 65 78 2E 68 74 6D 00 00 00 - .../index.htm ... This does not look like a problem with CF, since you are serving a .html file (right?). This looks like some corrupted messages. It could be a bug introduced by Adobe, some network problem, etc. I did a Google search on "Unknown AJP protocol code: 0F" and there's some concern that you might have mismatched max_packet_size. Can you check these between httpd and Tomcat? It looks like some folsk are grasping at straws... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTR4eXAAoJEBzwKT+lPKRY/ekP+wW1Po57MDsHqzc473AjXcNF qqry4V0r57HfcmaerO0z6kudJ5tfUTqJb9Pz/faiVZwofBRmH8yvM4/X8zbFvlbE gHXdMOsSa3w0yJ2zXKC9bdoE4bs/TTn3chCCXjLKRqGcgyzzk70+5iqA0r19jDiF N0xcKKz3KeJBZlwELCxsRjfWf5EtpyvJvjp7SvLHo0SQYAc6gYLCPMe6Sxs0RSVF ZrNLnqiVkNAez9rqPIsXvfq1DP7qQtjDkzLuKbDvOksbb6INUWpTznbiL6fRPWdl OwC/1cQZGRhz9GXMrmINRzjKBjbdsr1rmT5CR8ydQzMgFUzEdHTSNeYOVvdorjU8 PJZbzbYWMCXyP46q6aL+KBXcJDQrbmJlXtGbNhpsa14W+kE50TtDnAFgsWlkzMg4 DTSSscWZKIWNw0WysrPAKwqy/A3nMgLrKaz+xqdwyVHiNf7BMhPOPJokWDqJZV7t 0guQlY3F9BJk2oUirBuXrgM3hyu6vrSwCciDQ6iBHR9d4YluXzOLV4IFNrLHs55u yVWz+tdipX9DNueQJVZzbZ+8+f5pbv+0TRc9ltbomK66uh6rtQE5ubi3GumHJtHr srKc4Te4mOGScGoqqEnsX0/qgcU6GmQPMRXgABHVm4H5hd+F9CJ9WRMLaiYEMuib zcejLSi07ZsRDFSuc+3w =FwOd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39
Chris, Thanks for your regular guidance and valuable suggestions! On Fri, Apr 11, 2014 at 11:33 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Daniel, > > On 4/8/14, 6:36 AM, Daniel Mikusa wrote: > > On Apr 8, 2014, at 8:22 AM, Saurabh Saraswat > > wrote: > > > >> Dear Dan, > >> > >> Thanks for taking time to respond me. > >> > >> My updated Resource Tag is - > >> > >> >> type="javax.sql.DataSource" maxActive="100" maxIdle="30" > > > > As Chris mentioned, set maxActive 1 in your dev environment. That > > will help you find the problem more quickly. > > > >> maxWait="1" username="usrname" password="password" > >> driverClassName="com.mysql.jdbc.Driver" > >> > >> > url="jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull" > >> > >> > validationQuery="Select 1" removeAbandoned="true" > >> removeAbandonedTimeout="1000" > > > > This is in seconds, so 1000 is 16.667 minutes, and is probably way > > to high. > > > Whoops! You're right. I'm used to everything being in ms. I apologize > for my post just now: it's seconds and you are correct. 4 days of > conference+drinking will do this to you ;) > I can understand :) I have done all changes suggested by you guys and the good news is that the problem has been solved. Now my application is running fine. > > > For the purposes of debugging, try something much lower like 10 > > seconds. That way you'll get feedback quick feedback. > > +1 > > >> I have also cross checked my code. I am closing the connection > >> properly in finally block. > > > > If you have not done so already, run something like FindBugs on > > your code. > > Absolutely. FindBugs is a great tool, even though there are sometimes > a lot of false-positives. Run it on your code (it's easy!) and start > with the highest-priority bugs that it finds. They are pretty much all > worth investigating. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTR4WaAAoJEBzwKT+lPKRYNskP/RQJlQONYDDNa3qokJUoicNr > 3zqPd9w6SSvEvZnNfwR6G5a8EI/bDr4xQoEqOQfNBv6QSHrWaEBWmSkQwT/qcVh5 > QMOCZ+QMtCCQVD9KtYEwwHJH2FSpv9jEiBVyiPV8Ik4hMOYhIMgcJd+C1qh4Hj7s > fAfUsJ0aSZxQqexwHADhtn5UZP6/y+2DZGRZ1YVcCXmV7aPV4ghB1Nj7rY0EOxXq > N6q1dt9SsxNXnzqx3xNyJw20qulTa+//B4DNSjpek87cCf+PGMr/M9qV3pqrDBv6 > uBIUDWhZXaVa1ilGvyWilr9HnxTUh6JGGQEEgFNfafjO6DDJLteLFsp334QKDX+K > QBp03mU7gOO7QwcEtQ49XBmzEgy1//f44m4q9uU3LyZYleT8YRs479us2gHXUbYB > iVFOz1kqdFZOL4234zTE7MHkDTSd1o5lwfrzjghT+2On3/nEDYlrsmmcPkBSaVw9 > XFYucvC8gXx0CLFlyaPoobwUbVF0qmjEH1Np31tiLCjXDdfsI/2Im1TZDPNCfFnv > mj7+FA/h6PXV/kSrSdICjW2H38YeWI7CovUwNm3KnfTiLPC9clpJUUxXCrQWqo/+ > z6gv7V0dMRso9lXBFKKh6tGosGC3Q4NPJeqyfDbLUd4lS4HvrwFn9GvJF7Y1xD/+ > cKIkLEYn3Njl7Xz9I4Cj > =W5a2 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > regards, Saurabh
Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 4/8/14, 6:36 AM, Daniel Mikusa wrote: > On Apr 8, 2014, at 8:22 AM, Saurabh Saraswat > wrote: > >> Dear Dan, >> >> Thanks for taking time to respond me. >> >> My updated Resource Tag is - >> >> > type="javax.sql.DataSource" maxActive="100" maxIdle=“30" > > As Chris mentioned, set maxActive 1 in your dev environment. That > will help you find the problem more quickly. > >> maxWait="1" username="usrname" password="password" >> driverClassName="com.mysql.jdbc.Driver" >> >> url="jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull" >> >> validationQuery="Select 1" removeAbandoned="true" >> removeAbandonedTimeout=“1000" > > This is in seconds, so 1000 is 16.667 minutes, and is probably way > to high. Whoops! You're right. I'm used to everything being in ms. I apologize for my post just now: it's seconds and you are correct. 4 days of conference+drinking will do this to you ;) > For the purposes of debugging, try something much lower like 10 > seconds. That way you’ll get feedback quick feedback. +1 >> I have also cross checked my code. I am closing the connection >> properly in finally block. > > If you have not done so already, run something like FindBugs on > your code. Absolutely. FindBugs is a great tool, even though there are sometimes a lot of false-positives. Run it on your code (it's easy!) and start with the highest-priority bugs that it finds. They are pretty much all worth investigating. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTR4WaAAoJEBzwKT+lPKRYNskP/RQJlQONYDDNa3qokJUoicNr 3zqPd9w6SSvEvZnNfwR6G5a8EI/bDr4xQoEqOQfNBv6QSHrWaEBWmSkQwT/qcVh5 QMOCZ+QMtCCQVD9KtYEwwHJH2FSpv9jEiBVyiPV8Ik4hMOYhIMgcJd+C1qh4Hj7s fAfUsJ0aSZxQqexwHADhtn5UZP6/y+2DZGRZ1YVcCXmV7aPV4ghB1Nj7rY0EOxXq N6q1dt9SsxNXnzqx3xNyJw20qulTa+//B4DNSjpek87cCf+PGMr/M9qV3pqrDBv6 uBIUDWhZXaVa1ilGvyWilr9HnxTUh6JGGQEEgFNfafjO6DDJLteLFsp334QKDX+K QBp03mU7gOO7QwcEtQ49XBmzEgy1//f44m4q9uU3LyZYleT8YRs479us2gHXUbYB iVFOz1kqdFZOL4234zTE7MHkDTSd1o5lwfrzjghT+2On3/nEDYlrsmmcPkBSaVw9 XFYucvC8gXx0CLFlyaPoobwUbVF0qmjEH1Np31tiLCjXDdfsI/2Im1TZDPNCfFnv mj7+FA/h6PXV/kSrSdICjW2H38YeWI7CovUwNm3KnfTiLPC9clpJUUxXCrQWqo/+ z6gv7V0dMRso9lXBFKKh6tGosGC3Q4NPJeqyfDbLUd4lS4HvrwFn9GvJF7Y1xD/+ cKIkLEYn3Njl7Xz9I4Cj =W5a2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SQLNestedException in Connection Pooling With Tomcat 7.0.39
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Saurabh, On 4/8/14, 6:22 AM, Saurabh Saraswat wrote: > Thanks for taking time to respond me. > > My updated Resource Tag is - > > type="javax.sql.DataSource" maxActive="100" maxIdle="30" > maxWait="1" That's a lot of connections. Are you sure you need to be able to support 100 simultaneous queries? > username="usrname" password="password" > driverClassName="com.mysql.jdbc.Driver" > > url="jdbc:MySQL://localhost:3306/MaxDB?zeroDateTimeBehavior=convertToNull" > > validationQuery="Select 1" removeAbandoned="true" You should use "/* ping */ SELECT 1" as your validation query. The MySQL driver will perform a lightweight connectivity test instead of actually executing that query, which will improve performance. > removeAbandonedTimeout="1000" 1 second for abandoned timeout? That seems low. > logAbandoned="false"/> I highly recommend that you set this to "true". > I have also cross checked my code. I am closing the connection > properly in finally block. How about Statements and ResultSets? I think the MySQL driver (and db) is tolerant of sloppy resource management, but Oracle certainly isn't. > Also have set the max_connection=250 in etc/my.cnf for MySql. That just seems like a huge number. You really ought to set connection limits based upon user id. You don't want to lock-out root from your database if your web application runs away with the database... > Even now i am not getting any Exception but my Application gets > Hanged after a certain time (after Certain hits to the database > from application). Have tested pooling with different ways like > after setting - > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". > > Conclusion is that i am not able to find satisfactory solution. I agree with Daniel: you need to take some thread dumps when the application "hangs". - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTR4TZAAoJEBzwKT+lPKRY3WcP/itpZZE7WZqM9B3fSsDNFXmq 7jm6Wpzujj2pLNjUmtzKaSk44e1XgQTQ07LoxS0b3SLPpRi7yz6KbzCeQCOzQ6KE OXVj7d3plRReg5P2HaSL6FYfYDDh2ql/tKaEEnXVXOvCLI83UEnTnN2ENrsbXwEF Lx+t2mEfX00GlENqasheX6/hcDlHDiSJlccRBGbyF9cXHTF1YFLVJl4vT3R35uwm myiPTepohDAMH4zZ1s2hzQynGpUb69/dnaIopM+BE86YavfKhuNntdFhMF9kaTOQ s7A8UpyGgR4qaCH8qeHDC+brIJVtoVPTnBrcVKiU8oLFY2+K0vCN6tutBQrHTcRz HmYN638X3u6OyHY6nS+N2oEDLzZ/CLV2dntAXhEwOojiePq1mVdDDU48VUAT1ghD BS26DPquhSpedq/XgIrxmaNX69qjb5IWWD9b/0LuxoXSTriuK8Gjhyq2xDYxhoFP 5MZLf5ebUofZsw2qYVijYvy1vXLw96HruCNQMQCzis4Zo+pEt1jk+JT4gzZmrq5o fH0bvAvLriPSYR6STeJAs2/eJ8cOCoi8Vq5AF5NAq5XZGhLnQHbF0WYmHk/ZGen3 WSUhlGXYgFIK3Pf2NRGhf0cnu7gWKighhwqsNB135R7HlPeAg/RwrIcxAdckDULz FYXDKJS+U8HZdiCOoiaQ =JYNR -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 monitor performance of tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 4/8/14, 5:24 PM, Christopher Schultz wrote: > Randir, > > On 4/8/14, 5:05 AM, Randhir Singh wrote: >> We have an application which has JBoss as the application server >> with Tomcat as the web server, our application has Oracle 11g as >> the database. I would give some further background to the issue >> we are facing, since the last 1 1/2 months, the application >> slows down. Sometimes it comes back to normal, specially on >> week-ends. But other times we restart JBoss & Tomcat to bring >> back the application to normal. > >> We have been using jconsole to monitor tomcat like > >> jconsole 10.101.17.79:8891 > >> which monitors our tomcat for a work order system. If the memory >> usage does not show spike and shows constant reading, the GC >> button is clicked to invoke the garbage collector. > > You should really never have to invoke the gc yourself. It gc > isn't working properly by itself, you have a big problem. > >> I checked out on the net and got some clue as below: > >> 1) Javamelody - It seems to be a 3rd party tool which is not >> recommended. > > Javamelody is just fine. What makes you think it's not > "recommended"? > >> 2) There is a command mentioned to see the admin console, >> http:/// but it is not displaying the required page. > >> Please give your inputs whether jconsole should be a help in the >> right direction or some other way to monitor the performance of >> Tomcat. > > I suspect there's no chance you are in Denver for ApacheCon right > now, are you? I'm giving a presentation on it tomorrow. I'll post > the slides later in the afternoon MDT. http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20Apache%20Tomcat%20with%20JMX.odp There's a PDF version with borked slide-notes in that directory if you can't read ODP. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTR4NaAAoJEBzwKT+lPKRY24sP/1Ij7ECLYe+EqRiOb92EWjHg u1ZP718/HhhffBOeAqnz8G3i9aahG84cJTyUDUdAMnuTIR2r+ERpAgCpzY+18Xuf az1fnzMc7ko77gjqR3cIT7QklVAsDiiqYrvN28GhPLaEY4Lpsod+x04f9euVGA1O uf9MJxP+7z62/xdzI/fjfx5sK+k8I+2cfHPtOh67qSAa9QpSfRsP3M2GhbV9YK9Q +ssn7+3bsTDsemsr7osWP5Rbm7dZfXo/lV8qhCWhxvU+LKEmvN2HAjTBd0decHRI 9eV7MDE9VaozCuLIiOqwaC8KXQQyQARszKC16lP1Nbb5JaiQADz2pYANVhieS2cz VfhehXOq4jVPnMIo83RxIg+YwkQYHoU6KQoHEzPRIE5Mp1f9QtBfYAJ0AoKW6d90 D02H3Djp2To1x9nzDBU0bS1j0es+IvskVzTKPp1dndRZXKBVfpodqFIkuEKMNHRT ipG6s52APovZXBnXIXL7Ojwvm6vJ4EvbqEWKx13c+iEO7g9n1CDC/xVX0sU2TFcD 5DZHOwJdvpKXKyGXxygE5GRF5HpzBmuY308asBWk71WYAk6eHYeEP25q5y8YUXck Sb1omBGCB52YjDYgGKzTCBn3YfpsKfZHSWQfnQTCCfJC/oqkk54a7+k6hbkHc439 AHkRBrmf4Y25a93aihoS =y/w8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] How can I tell which version of OpenSSL is being used with tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 4/10/14, 3:06 AM, Konstantin Kolinko wrote: > 2014-04-10 12:25 GMT+04:00 Christopher Schultz > : >> >> (...) >> >> Andrew, if you haven't changed the Tomcat default configuration >> and you used the service installer, you likely have a vulnerable >> server depending upon exactly which version you installed, >> because the installer automatically installs tcnative, and the >> default protocol in server.xml (HTTP/1.1) auto-prefers the APR >> connector to the BIO connector. >> > > The default configuration is NOT vulnerable to HeartBleed. as the > HTTPS protocol is not enabled by default. You need to generate or > buy a server certificate and configure it to enable HTTPS. You are correct: the default configuration has SSL disabled. But, since this was a question about SSL, I figured that the OP had SSL enabled. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTR4K5AAoJEBzwKT+lPKRYJ7oP/jKhBgd9tTFdMC+NFNhA8T4x Qv/ffTpBx24RMk3+bNQFb4bBtnH9wNIbpR+MI8KM4fRvrtLy/8rtFo84GShq4GaD dPGkOUtkSrLVFX3utG5+wt301kZGS17cbXg1wTy/2jdsI+AuAZ6ur/lT8LDMtaak 8OTiQvRcb6ToKARPgXx7S/+7dHhdfuQJFA++jLc9OUFfmdNZzhyhkJnMDhbtVbCn 2doCqQe6JbRBONwqDJX/RYxOjUlLjiJqaZsMHpasCVwf1+TukTySURNkV68IAa+E NPOR6u7s5H3FfuFj0dLYUIrIQ8AoI4EtwX+T7eYZRS3tZwClaf1woIll01TEWKm8 G4KqmFcFvoh9T6jTJBCDhYgb18Z4+0LWMWEe0iHjzcNdATM++8b+CmkIFyc0oU10 MjxBo36HbAdtGG42MtLXg9IkTSYzmfCFnFiJyhFq8C42H10IM1XNsT8D3gX5+c9A htHcoPmrMwn0ExVuGstyHHJgoXqICuUU3dRRAA9VCJ42hslpaM8l19wzHAkGDVNd LbvQUBZZWv7mBGdsEXW6lpn4WDi5nF8OOSPmN8c2X14XPcONfsu7CqIA3q0IXjcJ wIpC4A8s82WR+xQXDuSE2im1oSYNTENTfdpnfEz6h9V/brSD6yZ1stue4PgdqtrU Zg71tWDYQip36e7SJpMU =th+K -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 4/10/14, 3:32 PM, James H. H. Lampert wrote: > On 4/10/14 2:10 PM, Ji Song wrote: >> Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I >> noticed that Tomcat native connector version 1.1.22 uses : >> OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but >> 1.1.24 and 1.1.29 also include the buggy openssl. > > If you use JSSE for your SSL support, then you're not affected, no > matter what version of OpenSSL your Tomcat uses. +1 Conversely, the version of Tomcat is not relevant, here: it's only the version of tcnative you are using. If you have 1.1.23 or earlier, then you are safe from this particular vulnerability (but there may be other issues with older versions). If you are on 1.1.24-1.1.29, then you have been vulnerable. tcnative can be used with any version of Tomcat, though certain versions of Tomcat have minimum requirements for the tcnative version. I can't stress enough that once you update to a fixed version, *you must re-key your server* and obtain a replacement certificate from your CA. You must also consider any communication that traversed your system while vulnerable to be compromised. That means that every password that went through your system during the period of vulnerability ought to be changed. > Kind of makes all that futzing around with Keytool (because JSSE > is apparently the only SSL option for Tomcat on an IBM Midrange > box) all worth it. ;-) Erm, maybe not. ;) You can actually use pkcs12 and avoid using keytool altogether. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRxbBAAoJEBzwKT+lPKRYnH4QAJwy4GbC4hLHIXZ3nn+slf9G 3NWGlpLo9Ua6ft4SvEiVxfWJ6hqShlWm6XcLwVjfG9TdAjL5NgXkQL5fXS/eWHTM 0HgMJnkkc6xPn/BgPpno9CcOcboBdH0wT+eazhuurKF7qdpancaujKbA2tf+gA59 929DbZTJLBSvYpY7eevdiIiFCzKrgUkpKUIOhj3QY8GsT2sfiMeSuY3R2X9CoSNa Jt8Zdew2eSsOTWURgeOFRfobKHDc2dIC9Z2/O0lUac16W8+IaM7rjzuXEGaZGUb2 6v0+CuMeGcoHpUg7h7P2xD1CgqR3U1MfSD8IEhW2axi3h9Z4DpsjZG8CTbgV2EDX zaZnv9cZld03j8efCkviYDM6LI4PY3H3/+gzIHvjzVdqLXACIyivYsEfLNw7/b7v 3TVB57dmB8At87WgH/15EHoJRPg75TtFC41YQLMXF/GrTE/GSrYnjjqLCVh+Yf+B nl/yVbGgDh+BLXlcVw9qMc7WCTkYLIi5ga3doh+i+fOYOQ/sLF+NWpTF1I2Nj7bR ilVS4nSAFPhrl/jbZxN7ojCyuo30/p0pDRKktZk/wGVj5Jgn9QSirEEjbLT1O9Au reEmnc25okkviPNFdHmxuDaSJIfLdCrXXGxpt6qWQ9Mcan/3X7boo8GAFZTLvsEM FAva6x+0v5/Gw/2Xc/88 =w2/Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 4/10/14, 10:39 AM, David Landis wrote: > On Wed, Apr 9, 2014 at 1:24 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> >> >>> (Checked http://filippo.io/Heartbleed before and after) I built >>> APR and Tomcat Native from source on the server, so I assume >>> it's doing dynamic library loading. >>> >>> Is the binary build staticly linked? Otherwise, I'm not sure >>> it's necessary to redo the builds. >> >> The ASF only provides binaries for win32, and yes, they are >> statically-linked. Users without the expertise to build their >> own tcnative binary will have to wait for the tcnative team to >> roll a new release. >> > > > What about for Linux? If you originally compiled libtcnative with > an older OpenSSL, is it sufficient to simply upgrade that OpenSSL, > or does the libtcnative need to be recompiled? Thanks. Most people use dynamically-linked libraries in Linux (or everywhere for that matter... the static-linked win32 library is done for particular reasons). So simply upgrading OpenSSL on Linux will usually take care of everything. If you happened to build tcnative yourself and did so with static-linking against OpenSSL, then you'll have to re-build. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRxUuAAoJEBzwKT+lPKRYLUkP/0TG7KSOrwjb9T8bum8OQgMO FUduF+ejGmZLG9M/Y/Z91kuSsQiGpri/ZCNWrewtctUgPoxK9Id9glCMnsN/IlY5 ZB/jBaJAvisqsT/fqivUwIUtUdKi03Wu8P1KfbZdfJtb7ebp/Y6vFfT4hY5z3UjK U88jYmvqy0+rlaBmOHevxImxaiIAtpGxUNUFD5JkJT3EhWHQxruIUfaNhthO0NSD ODP7iGb4HwaRPpaE97LUNquNuFBtDJKuXjo7b9JxiePZmhkhh5WNFbwYDcU1Wp/L aBX8TQKN0Wka7qnYUmk4iIqJgRPvNBOgWPKduvQ8Ptl3jlRUy9QxJ5HB4pSXjozl ToeczGloWDPXdbLLAKSszyefIVQ5IFk6wI2nR3xsxlVbZ612NwoEaa+wjh+gwrSJ sh4d1e7Xl1qSX58+AvT+GI/XgP779J6sP3hrCTapeUpD9wxocuepAMfvWgkFm6lT b94eaH08cf5uV/jqQJvGFwjRC9dIScWLASVPOw6qE7X1yeqwLH/kYeS6CtxepEFl c2xia48bQVP04ivEWa16JQY3+mx/x6KT+/pFdZMDgagfKcHDIgwF6G+cuT43y4rc Twu1yBPfZlGSt2ZYNUVxsdaGcjy8CNYDGroGCSonaP6hZAu9L92muY/UvkEYaFoW KVGeOMVS/5NCSdiUCGoF =J2qI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.5 and web resource cache
On 10/04/2014 02:02, Thomas Scheffler wrote: > Hi, > > I recently noticed that Tomcat 8.0.5 does not invalidate cache entries > for web resources. The cache has a default TTL of 5 seconds. > Here are the steps to reproduce: > > 1. make "/foo.html" available through a jar file -> > META-INF/resources/foo.html > > 2. Open foo.html in your browser > > 3. Add a new file "foo.html" inside you webapp directory with different > content. > > 4. Refresh foo.html in your browser. > > One would expect to see the content of the file that was added in step > 3. But Tomcat caches the URL it resolved in step 2 and sticks to it > forever. This is new in Tomcat 8. The cache validation that occurs once the TTL has expired doesn't catch this case but it should. I'll take a look. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
On 4/10/14 2:10 PM, Ji Song wrote: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. If you use JSSE for your SSL support, then you're not affected, no matter what version of OpenSSL your Tomcat uses. Kind of makes all that futzing around with Keytool (because JSSE is apparently the only SSL option for Tomcat on an IBM Midrange box) all worth it. ;-) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Hi I think it is tcnative.dll. You should find the tar.gz file attached with the source, which says you the version. Best Regards, Sasi Eswaravaka -Original Message- From: Ji Song [mailto:s...@glimmerglass.com] Sent: Thursday, April 10, 2014 4:11 PM To: 'users@tomcat.apache.org' Subject: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x Hi, Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. How can I find which version of Tomcat uses which version of Tomcat native connector ? For example, how can I figure out which version of Tomcat native connector is used by Tomcat 7.0 build 47. Thanks, Ji CONFIDENTIALITY NOTE: The information contained herein this email is intended for the exclusive use of the original recipient. The information in this email and any attachments is granted for the sole use of the intended recipient and may be distributed within the recipient's organization only with the permission of the sender. Any further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. If you are not the intended recipient, please contact the sender immediately and permanently delete the original email together with any copies thereof, including any attachments. Thank you for your cooperation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
On Thu, Apr 10, 2014 at 2:10 PM, Ji Song wrote: > > > Hi, > > > > Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that > Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't > have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy > openssl. > > > > How can I find which version of Tomcat uses which version of Tomcat > native connector ? For example, how can I figure out which version of > Tomcat native connector is used by Tomcat 7.0 build 47. > > > Look here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_47/build.properties.default Scroll to the # - Tomcat native library - section
Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Hi, Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. How can I find which version of Tomcat uses which version of Tomcat native connector ? For example, how can I figure out which version of Tomcat native connector is used by Tomcat 7.0 build 47. Thanks, Ji CONFIDENTIALITY NOTE: The information contained herein this email is intended for the exclusive use of the original recipient. The information in this email and any attachments is granted for the sole use of the intended recipient and may be distributed within the recipient's organization only with the permission of the sender. Any further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. If you are not the intended recipient, please contact the sender immediately and permanently delete the original email together with any copies thereof, including any attachments. Thank you for your cooperation.
Re: 7.0.23 vs. 7.0.52 startup times
2014-04-10 22:28 GMT+04:00 Shanti Suresh : > Greetings, > > There appears to be a hold up in 7.0.52 at startup as compared to 7.0.23 - > a matter of several seconds initializing each context. In 7.0.52, the > delay appears to happen at "findResources" when the > "javax.servlet.ServletContainerInitializer" is identified. Such a things > does not happen in v7.0.23 . My question is why is this service being > looked for when I don't have such a service file in my context's META-INF > directory? A run of both in DEBUG mode shows the following, where > findResourcses starts at "13:06:48" and goes until "13:06:51" in v7.0.52: > > (...) FAQ: http://wiki.apache.org/tomcat/HowTo/FasterStartUp - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
7.0.23 vs. 7.0.52 startup times
Greetings, There appears to be a hold up in 7.0.52 at startup as compared to 7.0.23 - a matter of several seconds initializing each context. In 7.0.52, the delay appears to happen at "findResources" when the "javax.servlet.ServletContainerInitializer" is identified. Such a things does not happen in v7.0.23 . My question is why is this service being looked for when I don't have such a service file in my context's META-INF directory? A run of both in DEBUG mode shows the following, where findResourcses starts at "13:06:48" and goes until "13:06:51" in v7.0.52: -v7.0.23 snippet:--- ... 2014-04-10 12:49:01,181 [pool-3-thread-1] DEBUG org.apache.tomcat.util.digester.Digester- Fire end() for org.apache.catalina.startup.IgnoreAnnotationsRule@46c51ce4 2014-04-10 12:49:01,181 [pool-3-thread-1] DEBUG org.apache.tomcat.util.digester.Digester- Fire end() for org.apache.catalina.startup.SetPublicIdRule@5a6d6fc5 2014-04-10 12:49:01,181 [pool-3-thread-1] DEBUG org.apache.tomcat.util.digester.Digester.sax- endDocument() 2014-04-10 12:49:01,182 [pool-3-thread-1] DEBUG org.apache.catalina.core.StandardContext- Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 2014-04-10 12:49:01,183 [pool-3-thread-1] DEBUG org.apache.catalina.core.ContainerBase- Add child StandardWrapper[jsp] StandardEngine[Catalina].StandardHost[localhost].StandardContext[/earthling] 2014-04-10 12:49:01,183 [pool-3-thread-1] DEBUG org.apache.catalina.util.LifecycleBase- Setting state for [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/earthling].StandardWrapper[jsp]] to [INITIALIZING] end of v7.0.23 snippet v7.0.52 snippet:-- 2014-04-10 13:06:48,796 [localhost-startStop-1] DEBUG org.apache.tomcat.util.digester.Digester- Fire end() for org.apache.catalina.startup.SetPublicIdRule@386eaf0d 2014-04-10 13:06:48,796 [localhost-startStop-1] DEBUG org.apache.tomcat.util.digester.Digester.sax- endDocument() 2014-04-10 13:06:48,797 [localhost-startStop-1] DEBUG org.apache.tomcat.util.scan.StandardJarScanner- Scanning JAR [file:/opt/tomcat/apache-tomcat-7.0.52/common/lib/json.jar] from classpath .. 2014-04-10 13:06:48,803 [localhost-startStop-1] DEBUG org.apache.tomcat.util.scan.StandardJarScanner- Scanning JAR [file:/opt/tomcat/apache-tomcat-7.0.52/common/lib/vgnhpd-7.1.jar] from classpath 2014-04-10 13:06:48,803 [localhost-startStop-1] DEBUG org.apache.catalina.loader.WebappClassLoader- findResources(META-INF/services/javax.servlet.ServletContainerInitializer) 2014-04-10 13:06:51,289 [localhost-startStop-1] DEBUG org.apache.catalina.core.StandardContext- Setting deployment descriptor public ID to '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 2014-04-10 13:06:51,290 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase- Add child StandardWrapper[jsp] StandardEngine[Catalina].StandardHost[localhost].StandardContext[/earthling] 2014-04-10 13:06:51,290 [localhost-startStop-1] DEBUG org.apache.catalina.util.LifecycleBase- Setting state for [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/earthling].StandardWrapper[jsp]] to [INITIALIZING] --end of v7.0.52 snippet--- Could I avoid this particular delay? Thanks, -Shanti
Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?
On Wed, Apr 9, 2014 at 1:24 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > > > > (Checked http://filippo.io/Heartbleed before and after) I built APR > > and Tomcat Native from source on the server, so I assume it's doing > > dynamic library loading. > > > > Is the binary build staticly linked? Otherwise, I'm not sure it's > > necessary to redo the builds. > > The ASF only provides binaries for win32, and yes, they are > statically-linked. Users without the expertise to build their own > tcnative binary will have to wait for the tcnative team to roll a new > release. > What about for Linux? If you originally compiled libtcnative with an older OpenSSL, is it sufficient to simply upgrade that OpenSSL, or does the libtcnative need to be recompiled? Thanks.
Best practice to programmatically get the disableURLRewriting context attribute value
Tomcat version 6.0.x on Linux OS
Hi all,
I have an application deployed on several customers Tomcat servers.
The Tomcat versions are different (6.0.16, 6.0.37, etc.) and asking all
customers to upgrade to the latest Tomcat version would be too tricky.
I would like to programmatically get the disableURLRewriting context
attribute value, when it exists (i.e Tomcat 6.0.30 onwards).
My purpose is to add a tuckey.org/urlrewrite filter rule that redirects the
user to an error page when the 'jsessionid=' string is detected in the URL.
if (disableURLRewriting exists and its value is true) -> the filter rule
should be applied
if (disableURLRewriting doesn't exist or its value is false) -> the filter
rule should not be applied because Tomcat 6 adds ';jsessionid=xxx' when
there is no cookie in the client browser
The only way that I have found to achieve this on different Tomcat versions
is to use Tomcat classes:
public boolean isDisableURLRewriting(StandardContext standardContext) {
Method isDisableURLRewritingMethod = null;
try {
isDisableURLRewritingMethod =
StandardContext.class.getMethod("isDisableURLRewriting");
} catch (Exception e) {
// the method does not exist or is not accesible
}
if (isDisableURLRewritingMethod != null) {
try {
return ((Boolean)
isDisableURLRewritingMethod.invoke(standardContext)).booleanValue();
} catch (Exception e) {
throw new RuntimeException("Unable to invoke the
isDisableURLRewriting method on the standard context");
}
}
// the method does not exist, we return false
return false;
}
StandardEngine engine = (StandardEngine)
ServerFactory.getServer().findService("Catalina").getContainer();
Container container = engine.findChild(engine.getDefaultHost());
StandardContext standardContext = (StandardContext)
container.findChild(context.getContextPath());
if (isDisableURLRewriting(standardContext)) {
// apply the rule
} else {
// don't apply the rule
}
1. Will this code work for every Tomcat configuration?
(I know that this code works when the context file is in the
conf/Catalina/localhost directory with the default server.xml file, but I
don't know if it will work when several hosts are defined in the server.xml
file, because I'm using engine.getDefaultHost())
2. Is there a better way to achieve this? (maybe without using Tomcat
classes?)
Thanks in advance,
Regards,
Lo
Re: Windows tcnative openssl ciphers question
On 04/09/2014 04:36 PM, Jeffrey Janner wrote: Per someone (Mladen?) the capability wasn't enabled at build. Last notice I received is he's addressing that in the next release. Yes, feel free to test candidate at http://people.apache.org/~mturk/native/1.1.30 which I hope will be voted as official release. It should have all the EC bits enabled, but this still needs some real-world testing. You're welcome :) Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can I tell which version of OpenSSL is being used with tomcat?
2014-04-10 12:25 GMT+04:00 Christopher Schultz : > > (...) > > Andrew, if you haven't changed the Tomcat default configuration and > you used the service installer, you likely have a vulnerable server > depending upon exactly which version you installed, because the > installer automatically installs tcnative, and the default protocol in > server.xml (HTTP/1.1) auto-prefers the APR connector to the BIO connector. > The default configuration is NOT vulnerable to HeartBleed. as the HTTPS protocol is not enabled by default. You need to generate or buy a server certificate and configure it to enable HTTPS. If you have configured HTTPS, then you should know what connector you are using, because the configuration attributes differ, as explained below. > To check if you are using APR, just check your > configuration. If you're specifying attributes like > SSLCertificateKeyFile then you are using OpenSSL (and still should > track-down the version). If you see attributes like "keystoreFile", > then you are using JSSE and you are not vulnerable to this particular > issue being discussed this week. > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Temporary mitigation of Heartbleed?
2014-04-09 23:18 GMT+04:00 Jeffrey Janner : > > Much as I loathe downgrading, would it be possible/advisable to downgrade the > native libraries to 1.1.23 with Tomcat 7.0.50? 1. There is a minimum required version of TCNative for every Tomcat. See constants in AprLifecycleListener source. 2. Old versions of OpenSSL have their own security issues. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Temporary mitigation of Heartbleed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/14, 1:18 PM, Jeffrey Janner wrote: > Much as I loathe downgrading, would it be possible/advisable to > downgrade the native libraries to 1.1.23 with Tomcat 7.0.50? Check the security and changelog pages? > That version is the last to use a pre-1.0.1 version of OpenSSL > (1.0.0g). I thought that 1.0.0 was also vulnerable. I think you have to go back to 0.9.8. Don't quote me on that. > This could help us at least until we get a blessed version from the > APR team? I'm sure the vote will be quick. Honestly, I'm already +1 for release even though it's not yet built. Any bugs in the release will be better than insecure OpenSSL. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRli+AAoJEBzwKT+lPKRYj24P/3ZkFPDvVYEIaAErjkNeuEiW julhkz4hSLSxso5B1ZfN/WaIKvCHwGwB/0flKTFfcCU+HBYqV/3ng7MnDpat8okE wq4bOcy3HN3gR5Ize+qtIqAsijbydvE4T9Ac8nw2GfvCDSiVf+nKuPxGJswdr9tS UglJb0iXnPexukz4iX2+wKdZBiooMYvgPupVotZ5koFO6DGlTpb/IlI74OmucvB8 s8BQrZC1gtWg8J/sZhlofE73DWctdIjmPQP0s6gvMh5J5gFeJXJK9I0+qRyFwAgh a/b9R6cpW/cj6exMZiC4bz0/VjrFU8ltu2tQJq/OXcdtIZ7WGYIVJYrhaSgkt0ml WVdI2j/I3K7PsWx95rbot9nmrDrJjaQ24yt80tEoWF63VQTJNuQXfLOEZahOJ5Ec HBesexx/syOSbRhyxk6XJsAZU0XQCnLPLlHnOdhr5PiSSj4U4Y99fFa7aPraXqEx BoAdV7fJWrnDDnDg3ySdcC+evto4/2BN3gxBsBSTvMl7oRxCg3UXeL8mb0AoNx60 CrU2a7mqKvfvHA3C3VxiFElreqO0uHM9XhaEsx0nXvLEtyq7Jsk/L3Xb92CX/wiu Kr/pAcPX43irymFkBfwHxPqmt1eUnk58BYw+dNEEzg6qh/pb6ggOuwrHvbiTZftD y4fcyXekKHAcfXvxk36E =HJO5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can I tell which version of OpenSSL is being used with tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 4/9/14, 12:59 PM, Jeffrey Janner wrote: >> -Original Message- From: Andrew Russell >> [mailto:andrew.russ...@gmail.com] Sent: Wednesday, April 09, 2014 >> 12:02 PM To: users@tomcat.apache.org Subject: How can I tell >> which version of OpenSSL is being used with tomcat? >> >> If I installed tomcat on windows using the service installer, how >> can I know which version of openssl was used? > [Jeff Janner] > > Did you select the Native Libraries when you ran the installer? If > so, you are most likely to be using OpenSSL for SSL services. How > can you be sure? Do you have any set up to use SSL? > Did you specify the protocol parameter when you created the > connector? If not, then the default is to use the APR library if > the Native Libraries are available and the APR Lifecycle Listener > is in your server.xml and the SSLEngine is set to "on". In other > words, you'll need to review your server.xml and the tomcat > documentation on configuring Tomcat to see if you are vulnerable. > > However, a perhaps easier way is to check your latest catalina.log > file. If it contains this line: INFO: OpenSSL successfully > initialized (OpenSSL 1.0.1e 11 Feb 2013) Then you are susceptible > (any version 1.0.1 < 1.0.1g). It's possible to be safe and still not have 1.0.1g. Debian, for instance, has shipped a patch to 1.0.1e to fix this problem but it does not have the feature changes of 1.0.1f and 1.0.1g. This is kind of what Debian does. *shrug* > Also, if you do have the native libraries in the bin directory, > you can check its version by hovering over the tcnative-1.dll file > and checking the value of File Version. The latest is 1.1.29, > which has the bug. I'm not sure at which release the bug was > introduced. The Bugzilla bug says versions 1.1.24 - 1.1.29. I haven't personally verified those version numbers. Honestly, your best bet is to run one of the HB testers online if you really have no idea what you're running. Of course, if you've patched OpenSSL (or your package manager has updated and you've updated and restarted Tomcat) then you'll never know if you *were* vulnerable. Andrew, if you haven't changed the Tomcat default configuration and you used the service installer, you likely have a vulnerable server depending upon exactly which version you installed, because the installer automatically installs tcnative, and the default protocol in server.xml (HTTP/1.1) auto-prefers the APR connector to the BIO connector. To check if you are using APR, just check your configuration. If you're specifying attributes like SSLCertificateKeyFile then you are using OpenSSL (and still should track-down the version). If you see attributes like "keystoreFile", then you are using JSSE and you are not vulnerable to this particular issue being discussed this week. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRlWSAAoJEBzwKT+lPKRYapsQAK6RlP6zHeh8+Sm4guaBdfIN 7K258eemdlg0TtqC3EZj0/2X+NNDG7Q74Dmi7V6r3TnVFitONdPic5WrDv+EQbmW ArVkwN4ibUV529ho66mb3bzYWkimX8ZzmTFqGQ0Cd+kokWjTYd2wzcz933UP00mS EogEQbjJfY+LYkujvsjsqFQhSt91bH9CGIcuwwzBpMjkNKmtVmO6O5izdemVh2gH JlGBzzaXUwPgfFTwP2WOGLzQk/40Or1ovRfXWbGeVnV9ThYZp62OZypeyKQVnRUg uusJX/Ikeqn+fGo+OavnzluY/n/e3Qsl7I9pjSW84y7Xz6I4BqJ2K92dJXkfztY/ +zf60n70AqhgMrT3GGiMbItflldex1cLaP1MIktZSJD+/ASjvmv6cVxhT6rZMB3+ riG3r/WJkDLbnj7uOWoZdYBiFfEric1rN2tL4hbjfNzHbQE9S7DCXVIuOypHBQkI 6nK7/Ez+3qdO29W3WxsYSH++07/wGuOFF44JcW64hh5gUauZUevhXBHzmQfVJz4T CgP2lhqCT+DBDbzYbmCRFXkA+gSloSb8G1zQJAG7Puhk+6gQg5TUr8oJ3lmV+nZv kFh0AX3OhGxSeJKLeO71DLGq3Uc1w0ee4Xom63GIbtPfsZYIirrjeJSbKO6jOBQQ Qt7KhUjjpajKHBIdxgn/ =6UQL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.5 and web resource cache
Hi, I recently noticed that Tomcat 8.0.5 does not invalidate cache entries for web resources. Here are the steps to reproduce: 1. make "/foo.html" available through a jar file -> META-INF/resources/foo.html 2. Open foo.html in your browser 3. Add a new file "foo.html" inside you webapp directory with different content. 4. Refresh foo.html in your browser. One would expect to see the content of the file that was added in step 3. But Tomcat caches the URL it resolved in step 2 and sticks to it forever. This is new in Tomcat 8. I would prefer that Tomcat always check the current webapp directory and uses it cache only for the *.jar files. kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
