On 11/6/23 5:21 PM, Nithiyanandam BALASUBRAMANIYAN (Oneberry) wrote:
I am using Tomcat Apache Version 8.5.94 in Windows server 2012. Recently
received following vulnerabilities alert to fix :
Short answer: you're already there. And the latest Tomcat 8 (which I
just bumped a customer up to)
On 11/3/23 9:33 AM, Mark Thomas wrote:
Alternatively, come along to the next Community Over Code conference,
take part in the key signing party and join the web of trust (or just
use this as the excuse to come to the conference).
And as a final option (I've done it once in 20 years) you can
).
--
James H. H. Lampert
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
I probably asked the question before, but does Tomcat have any problems
with not having a ROOT context?
--
James H. H. Lampert
Touchtone Corporation
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional
Java Keystores work. And I don't find them especially difficult to work
with (other than new formats not being backward-compatible with older
JVMs, and as one who has made a comfortable living banging out code for
IBM Midrange boxes for over a quarter century, I am quite familiar with
a much
Ladies and Gentlemen of Both Lists:
Last Friday evening, I ran into a problem updating SSL/TLS keystores on
two customer boxes, and spent three hours yesterday, finding the cause,
doping out a way to salvage the certs they'd paid for, and doping out a
solution to keep it from happening in the
On 9/8/23 8:34 AM, Ivano Luberti wrote:
I had similar problem with mod_security installed on servers and apache
used as proxy.
mod_security intercept the request and if considers it suspicious
generate a 403 error
Found it.
It's in the AWS WAF. A rule called
Yesterday, I discovered that our Tomcat-based webapp (running on a
Amazon AWS) doesn't like the word "localhost."
If I enter it in a text field, through the UI, it won't save the record,
and if I feed it into our web services, it comes back with a 403:Forbidden.
My primary hypothesis is that
Funny thing: we recently needed to update a customer's Tomcat because
they were complaining about a security issue that had prompted 8.5.88.
And by the time we got the update request, 8.5.89 was already out, but
we hadn't yet heard of CVE-2023-34981.
So we'd already skipped over 8.5.88
According to the Tomcat 7 configuration reference, keystorePass, if not
specified, defaults to the value (specified or default) of keyPass.
The Tomcat 8.5 configuration reference doesn't say this; is it still true?
--
JHHL
-
On 5/23/23 10:02 AM, Rob Sargent wrote:
Does pathLen:0 mean "no limit" or "no go"?
Well given that the "Basic Constraints" are exactly the same, across the
board, in *both* the keystores that worked fine and the keystore that
blew up, I don't think that's a factor. And the fact that the
On 5/23/23 8:31 AM, Christopher Schultz wrote:
Can you dump the whole cert (e.g. keytool -list -v -alias 'certname')
for each cert and see if any of the certificates specify a maximum chain
length somewhere? Evidently, it's an extension to the X.509 spec:
Comparing one that worked with one
On 5/18/23 1:57 PM, Thomas Hoffmann (Speed4Trade GmbH) wrote:
So the error is raised not by tomcat but by the ibm JDK.
Yes. The results reported in my latest email say as much.
Those results also say that there's something different -- radically
different, judging from the amount of red
Weirder and weirder. (And hopefully, my previous email, with a
catalina.out excerpt as an attachment, actually got distributed to the
List.)
I copied the cert and the unsigned keystore from my new Mac (M2 Mini,
running Ventura) to my old Mac (2017 iMac, running Catalina), and
signing and
On 5/18/23 12:18 AM, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Which version of tomcat do you use?
Is the stack trace truncated in your mail? Is there a "caused by ..." further
down the stacktrace?
It looks like the error is thrown deeper in SSLUtil when creating the ssl
context.
Maybe you
On 5/17/23 5:10 PM, Jason Tan wrote:
Have a look at this.
https://success.qualys.com/discussions/s/question/0D52L4To0DUSAZ/your-ssl-server-test-incorrectly-reports-an-incomplete-chain
That's actually my own thread, from a few years ago.
The problem here is not an incomplete chain, and
and intermediate as the last good keystore.
Can anybody shed any light on what went wrong?
Tomorrow morning, I'm going to try plugging the keystore into a Tomcat
server on an AS/400 in the office, to see if I can reproduce it.
--
James H. H. Lampert
On 3/8/23 4:06 PM, Christopher Schultz wrote:
SOP for systemd is to redirect stdout/stderr for the process into its
own logs similar to syslog (but different, of course, because #systemd).
This could also happen on Linux is you are using "jsvc" to launch
Tomcat. If you use the standard shell
On 3/8/23 1:34 PM, Zerro wrote:
On the Linux box Tomcat is probably started by systemd, therefore no
catalina.out
Very likely, but can you elaborate on that? I'm much more of a DOS (to
the point of having gone to great lengths to set up a refurbished
vintage notebook as a functioning
On 3/8/23 11:35 AM, Mark Thomas wrote:
Check logging.properties and/or how you have stdout redirected in your
start-up scripts.
Thanks.
All I see different in logging.properties is that on the Midrange box
(installed from the ZIP file from Apache's Tomcat site), it has
FYI:
The operating system on IBM Midrange boxes ("AS/400," "iSeries," "IBM
i," or whatever they're calling it this week) is "OS/400," "IBM i," or
whatever they're calling the operating system this week. These machines
are the descendants of the IBM S/3, which IBM Rochester developed in the
Dear Mesrs. Thomas, Schultz, et al.:
Changing it to "org.apache.coyote.http11.Http11NioProtocol" did the
trick. The Tomcat 9 server launched, on our cloud Midrange box, and both
it and the webapp contexts we have running seem to be working. It will,
of course, require a bit more exercise
On 03/03/2023 17:44, I wrote:
Ok, another question: will Tomcat 9 accept a "legacy" connector
definition in the form as shown below?
protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150"
SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/foo/tomcat/bar.ks"
On 3/3/23 9:51 AM, Mark Thomas wrote:
Yes.
Thanks. That simplifies things.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/2/23 3:50 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:
Yes, Tomcat9 runs under Java8 and above.
Ok, another question: will Tomcat 9 accept a "legacy" connector
definition in the form as shown below?
protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150"
Am I correct in my understanding of the Tomcat 9 RUNNING.txt, that it
will run under Java 8?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
If you haven't heard of the "Reach" blockchain language, this probably
isn't worth your time.
But.
Is there anybody here who has called a Reach dApp from a Tomcat webapp?
And if so, what's the most practical way to do it?
--
JHHL
On 2/23/23 9:17 AM, Mark Thomas wrote:
You need to remove the error page entry for 404 errors from
WEB-INF/web.xml rather than / as well as renaming / removing 404.jsp
Delete (or comment out) these lines:
404
/WEB-INF/jsp/404.jsp
Thanks. I really wish certain other
On 2/22/23 9:23 AM, Mark Thomas wrote:
Alternatively, you can use denyStatus="404" on the RemoteAddrValve. That
attribute should be available in all versions of all currently supported
Tomcat releases (it was added back in 2011). You can set it to any value
valid for use with
On 2/22/23 9:23 AM, Mark Thomas wrote:
Fire them and hire a security consultant with a proper understanding of
risk?
Pardon my Yiddish, but "Fun dayn moyl in Gots oyern." (From your mouth
to God's ears. Such a colorful language.)
But just because you're paranoid doesn't mean they're not out
We've got a customer -- the same one that was our first test of a
working RemoteAddrValve -- whose security consultant is complaining that
a potential intruder can confirm the *existence* of the manager context
(because it returns a 403, as opposed to, say, a 404).
Any ideas?
--
JHHL
Naturally, I thought about this about 5 seconds after I clicked "Send":
It doesn't happen very often, and it usually happens *after* a
substantial portion of the heap has been idle for some time. Maybe
there's something in there that works somewhat like a disk defragmenter.
And when it gets a
It would be unusual for the OS to reclaim any of that memory from the
JVM process. Are you looking at OS heap usage, or "JVM heap" usage?
From your description above, it's tough to tell. The tool is called
WRKJVMJOB so presumably it knows what the heck a JVM is, so maybe you
were getting the
I've obtained some heap and CPU numbers, taking data at 15 minute
intervals, heap from WRKJVMJOB and CPU from WRKACTJOB. In two days of
this, I didn't witness any crashes; I did witness a near-miss, in which
heap-in-use hit 5011.938M (out of 5120).
In discussion with our webapp developer (to
Monitored the thing all day, taking the CPU usage (via a WRKACTJOB) and
the current heap size and heap-in-use (via option 5 of a WRKJVMJOB)
every 15 minutes.
Heap size was 4925.375M (out of a maximum of 5120M) at 08:45, and the OS
took heap away over the course of the day, until it was down
Thanks, Herr Hoffmann. Your questions were most helpful in determining
what information to gather and share. And thanks in advance to anybody
else who has any insights.
First, I will note that the seemingly non-sequitur nursery-survivor
numbers aren't just what we see during a crash; they're
One of our customers, one who basically pushes our Tomcat webapp to the
limit, is having trouble with crashes.
Some interesting numbers are showing up in Server Status, in Manager:
nursery-allocate has initial 512M, total 1152M, maximum 1152M, used 587.05M.
nursery-survivor has initial 512M,
That I was "shot down in flames" when I tried to get in from my
Chromebook, through the hotspot on my cell phone, makes it unlikely that
Tomcat is seeing a proxy IP, especially given that (as I understand it)
I would have had to authorize the proxy IP to get in from my office IP,
and I have no
On 2/1/23 12:06 PM, Mark Thomas wrote:
The pen tester requested "/app/..;/manager"
The proxy passed that as is to Tomcat since it starts with "/app"
Thanks.
As it happens, this particular customer was the first one in which I
tried putting the only IP addresses with any business accessing
We got this from a customer who did a security scan:
A Tomcat Manager login panel was discovered via path normalization.
Normalizing a path involves modifying the string that identifies a
path or file so that it conforms to a valid path on the target
operating system.
QID Detection Logic: This
On 1/18/23 3:11 PM, Christopher Schultz wrote:
Tomcat is pure-Java (okay, except for tcnative, which you evidently
don't need) and therefore should run on either x86-84 Java via Rosetta 2
or aarch64 Java natively. You do not need any special distribution of
Tomcat to run on native aarch64.
On 11/15/22 9:50 AM, Mark Thomas wrote:
. . .
Is this from Tomcat, or is it from something else?
Lots of guess work here.
I think, something else.
. . .
It *is* from something else. I'd completely forgotten that on that
particular box, Tomcat was behind Apache HTTPD, and the relevant .conf
We have Tomcat running on an AWS EC2 linux box.
I can get into manager from the office IP address, with the usual prompt
for user and password, but the boss, working from home, gets "You don't
have permission to access this resource."
Is this from Tomcat, or is it from something else?
Lately, we've been getting this response to a web service call. The web
service is our own, running under Tomcat on an Amazon "beanstalk"; the
client is also our own, running on a customer's IBM Midrange box.
504 Gateway Time-out
504 Gateway Time-out
nginx/1.20.0
It's a
On 8/10/22 6:50 AM, Brian Wolfe wrote:
You can disable the protocols at the java level in the java.security file
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1,
TLSv1.1
I think that's exactly what I did on "Customer Box #1" (and forgot to
document having done).
On 8/10/22 8:52 AM, Jason Hall wrote:
If you have another network device in front of your server - that could be what
is trumping the app server's settings.
I'd planned on investigating that as well.
But it *looks* like the cert I'm seeing matches the cert in the keystore
their Tomcat is
Interesting. The new "protocols" parameter.
Does this work with the traditional syntax? Can "protocols" and
"sslProtocol" coexist in the same Connector?
All our customer installations use JSSE security with a Java Keystore;
I've never configured a successful IBM Midrange installation any
I think this may have come up before, but I don't recall how it was
resolved.
On customer box #1, I have:
address=""
maxThreads="400" SSLEnabled="true" scheme="https"
secure="true"
keystoreFile="/tomcat/wttomcat.ks"
keyAlias=""
Today is the first time I heard of such a thing as a "TCP timestamp
vulnerability." It seems a bit overblown to me, especially for a Tomcat
server running on an AS/400.
Can anybody share any insights about how this vulnerability relates to
Tomcat?
Multiple WAR files work fine for us. But we don't simply "drop [the WAR
files] in the webapps folder (and for the most part, that *doesn't* work
for us, even with *only one* webapp).
We always deploy through the Manager webapp (which we always customize
to increase the allowable WAR file size
In response to my question about what could cause a system to disregard
its own host table,
On 4/15/22 11:31 AM, Jack Woehr (of the Midrange List) wrote:
Which order the search happens, DNS or hosts table first, is an option in
IBM i TCP configuration. CFGTCP option 12.
Fascinating. I can't
On 4/15/22 10:37 AM, Christopher Schultz (of the Tomcat Users' List) wrote:
. . .
Try specifying the "address" attribute of along with the port.
Give it a concrete IP address instead of "localhost" and see if that
improves things.
. . .
My Dear Mr. Schultz:
That did it!
Not knowing whether
On 4/15/22 10:37 AM, Christopher Schultz (on the Tomcat Users' List) wrote:
. . .
if "localhost" doesn't resolve to 127.0.0.1 on your system, you
may get this error. Can you quickly check it's not a DNS resolution
failure?
THIS is interesting.
If I look at the host table entries, I see
On 4/15/22 9:54 AM, Jim Oberholtzer wrote:
On a modern system if you're contemplating stopping/starting TCP you might
just as well IPL. Seems like using a nuke when a 100# bomb might work
though.
Looking at the QSYSOPR messages, I see that the system was taken down to
restricted condition at
On 4/15/22 9:39 AM, Jack Woehr wrote:
Not sure about the particular pathology in this instance, but it's the Java
runtime itself telling you something already has hold of the socket, and
it's not lying.
But it could be deluded into *thinking* something already has hold of
the socket.
On 4/15/22 9:24 AM, James H. H. Lampert wrote:
This morning, I arrived at work to find that a customer was complaining
about their Tomcat server (running on an IBM Midrange box).
It had locked up last night, while being shut down, and now, if you try
to start it, it fails . . .
I tried
y insights as to what could be happening?
--
James H. H. Lampert
Touchtone Corporation
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
I'm doing some cleanup on a customer box, removing a previous version of
Tomcat 8.5 that I'd replaced some time ago, and I'm finding huge amounts
of "stuff" in the "temp" directory within the Tomcat directory. Is that
stuff Tomcat itself left behind, or stuff our webapp left behind, or both?
Thanks. I think I understand now.
All except for one thing:
I can *barely* wrap my mind around the idea of getting executable code
from an RMI server, but what legitimate purpose could be served by
allowing a *logger* to resolve executable code?
--
JHHL
(And I have a fair amount of
On 12/13/21 10:53 AM, Mark Thomas wrote:
Log4j2 supports a log message format syntax that includes JNDI lookups.
Log4j2 processes log messages repeatedly until it doesn't find any more
format strings. This means the output of one format string can insert a
new format string.
. . .
Thanks.
The thing I'm still utterly unclear about is how simply logging traffic
could, by itself, create a vulnerability.
In our case, the log entries are not even viewable unless you are signed
on to a command line session on the server (ssh for headless Linux; a
physical Twinax terminal, or a 5250
A customer brought this to my attention:
https://www.randori.com/blog/cve-2021-44228/
I have no idea how (or if) Tomcat is affected. I have only the vaguest
idea what this vulnerability even *is.*
Can anybody here shed any light?
--
JHHL
On 12/10/21 8:38 AM, Mark Thomas wrote:
. . .
The messages are there to warn you that you might have a malicious actor
trying a brute force attack on your server.
Can anybody point me to a good tutorial for constructing a regular
expression for RemoteAddrValve?
Could anybody here shed some light on this message? A whole bunch of
them appeared in catalina.out.
WARNING [https-jsse-nio-443-exec-29]
org.apache.catalina.realm.LockOutRealm.filterLockedAccounts An attempt
was made to authenticate the locked user [user]
--
JHHL
Also, based on what "yum check-update" returned, it appears that at the
moment, I can only go as far as 8.5.72, rather than 8.5.73. Is there a
way to go all the way to 8.5.73 without fundamentally changing how
Tomcat is installed on that instance?
--
JHHL
On 12/8/21 9:46 AM, jonmcalexan...@wellsfargo.com.INVALID wrote:
I think it's going to come down to how the 8.5.58 was installed. Was
it via an rpm or zip file? I have used both methods and you should be
able to install the 8.5.73 without affecting the 8.5.58. If you are
using a separated
We have a Tomcat server running on an Amazon Linux 2 EC2 instance.
Off the top of my head, I don't remember how I originally installed it,
but it's currently at 8.5.58.
I'd like to update it to 8.5.73, but I don't quite know how to do this
in Amazon Linux 2 (now if somebody asked about
On 10/14/21 7:12 AM, Mark Thomas wrote:
The fix for bug 63362 introduced a memory leak. The object introduced to
collect metrics for HTTP upgrade connections was not released for
WebSocket connections once the WebSocket connection was closed. This
created a memory leak that, over time, could
Our Tomcat team has been struggling with this issue for a few days:
If a request comes in for https://foo.com/bar.html, which doesn't exist,
then a 404 is returned, and we see a standard Tomcat 404 page.
But if a request comes in for https://foo.com/bar.jsp, which also
doesn't exist, then
I could have sworn I asked about this over a year ago, but I can't find
any record of having done so.
We've got a low-priority complaint about a security scan looking for
"test.jsp" on one of our installations, expecting a 404 response, and
instead getting a 200 response and a redirect to our
While we've been systematically updating our customer boxes, a few of
our customer boxes are still on Tomcat 7.
I've got the following Connector tag set up in server.xml:
compressableMimeType="text/html,text/xml,text/plain,text/css,
text/javascript,text/json,application/x-javascript,
On 8/9/21 11:33 AM, Mark Thomas wrote:
The fix will be in the September releases.
Thanks.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 8/9/21 10:24 AM, Mark Thomas wrote:
Future versions of Tomcat won't see this issue but if the customer is
prepared to update Tomcat to fix this issue then they might as well just
update Java (assuming that is indeed sufficient to fix this).
Given that they currently seem to be happy as
On 8/6/21 9:17 AM, Konstantin Kolinko wrote:
Try to find what *.jar file in your system contains the above classes.
E.g. searching for string "crimson" in *.jar files.
That string will be visible in the archive file as it is a name of a directory.
I've learned that QShell (a *nix-like shell
Searching JAR files for "crimson" would likely be an exercise in
futility on an AS/400.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 8/6/21 1:40 AM, Mark Thomas wrote:
Tomcat 7 doesn't have JASPIC support so you'll never see this issue in
Tomcat 7.
What's a JASPIC?
And as to configuration, Mr. Schultz, my usual procedure is to (after
commenting out the default 8080 unsecured connector) copy and paste the
active
I finally had a chance to switch the customer back to the failing Tomcat
8.5.68, and this is what the browser error page shows (with a 500 error):
Type Exception Report
Message AuthConfigFactory error: java.lang.reflect.InvocationTargetException
Description The server encountered an
Mssrs. Kolinko and Schultz said:
2. The stack trace starts with "Bootstrap.main". I.e. it is the thread
that starts Tomcat.
I.e. this occurs when Tomcat starts up and has nothing to do with your
attempt to access the Manager web application.
3. The stack trace contains "org.apache.crimson".
This is beyond my pay grade, I'm afraid. Hopefully somebody here has a
clue what went wrong.
I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been
running Tomcat 7 for years with no problems.
On launching Tomcat 8, if I try to connect to "manager" (the only
context currently in
First, understand that I have even less involvement in development of
our mobile apps than I do in the development of our Tomcat webapp. So
I'm grasping at straws here. All I know is that the mobile apps work
through the webapp.
It seems that at a specific customer installation, when the
On 7/2/21 12:02 AM, Mark Thomas wrote:
It is an alternative session manager that persists session data via a
configured Store. There are two Store implementations provided by
default - File and DataSource.
You would know if you were using it as it requires explicit configuration.
Thanks
On 7/1/21 4:55 PM, in response to:
I will note, however, that the Tomcat servers in question are
*not* configured to listen on any ports other than HTTPS (either
443, 8443, or something else in that vein) and the shutdown port.
Shawn Heisey wrote:
In that case, you don't need h2c, and
On 6/21/21 9:42 AM, Christopher Schultz wrote:
If you are using h2c, you'll definitely want to 8.5.63 or later, as
there is a critical fix there.
My understanding, based on what I looked up a week and a half ago, is
that we're not using h2c, but at the same time, don't think I fully
On 6/21/21 9:42 AM, Christopher Schultz wrote:
I think it depends upon your environment, honestly. There were many
organizations where the "AJP endpoint is trusting, because that's what
it's for" announcement was a real surprise and represented a must-fix
issue immediately. That was not the
We are finally migrating customer installations from 7 to 8.5.
Would anybody happen to know, off the top of his or her head, what the
most recent security-related update to 8.5 is?
I know that 68 is the most recent release, but what's the most recent
one that addresses a significant security
We are beginning to migrate some of our customers from Tomcat 7 to
Tomcat 8.5.
Some of them have performance issues even with heap allocations of
-Xms4096m -Xmx5120m
Would it be necessary to go even bigger with Tomcat 8.5?
--
JHHL
On 4/6/21 9:11 AM, Olaf Kock wrote:
*Everybody* has a dedicated testing system. Always!
*Some* are lucky that they have a completely separate production system.
We expect disk drives to fail. So we plan for it, using some form of
RAID (full mirroring in my case).
And so the power supply
On 4/5/21 1:22 PM, Christopher Schultz wrote:
If you are not running a reverse-proxy in front of Tomcat, then it does
absolutely nothing for you.
If you *are* running a reverse-proxy in front of Tomcat, then it *may*
do something for you, depending upon what software you are using and
what
We've just gotten a complaint about a vulnerability involving AJP (to
something called "Ghostcat") from a customer. The report from the
security consultant recommends updating to a more recent version of
Tomcat, and I note that we've already started rolling out 7.0.108 to
customers.
Looking
Thanks to all, for both satisfying my morbid curiosity and verifying
that it's the customer's problem, not mine.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
On 1/6/21 3:46 PM, Robert Turner wrote:
You'll want to set the protocols, ciphers, and honorCipherOrder ...
The precise wording in the error message is:
. . . but the server presented a certificate signed using a weak
signature algorithm (such as SHA-1). . . .
Which is to say, it doesn't
We just had our first Tomcat 8.5 installation on a customer's AS/400.
The customer apparently has his own CA (they're a big company), and when
I installed SSL in their Tomcat, and tested it with a browser, it
complained, something to the general effect of "weak signature algorithm."
While
On 12/22/20 10:51 AM, Christopher Schultz wrote:
I would try to lock-down that IP range as much as you can, rather than
either removing the Valve (which would allow connections from anywhere)
or specifying something like ".*" in the "allow" attribute (which is a
regular expression which will
A few months back, as I recall, I ran into some "gotchas" in connection
with the manager context, while setting up Tomcat 8.5 on one of our AWS
EC2 instances. As I recall, I had to do something special, somthing I
don't have to do with Tomcat 7, in order to make the manager context
reachable
Ladies and Gentlemen:
The same customer installation that required 104 (but with the 103
catalina.sh, to avoid Bug 64501) back in June is now demanding an update
to 106 because of the CVE-2020-13935 vulnerability.
Two questions:
1. Is the problem from June fixed in 106?
2. Does 106 take
On 8/21/20 1:02 PM, logo wrote:
From my experience I have excluded .well-known from the redirect.
That appears to be the correct answer. I probably didn't see that line
back in August, or I probably would have replied by asking something
like, "Ok, and how do I do that?"
Be that as it
On 8/24/20 9:57 AM, Christopher Schultz wrote:
So your RewriteCond[ition] is expected to always be true? Okay. Maybe
remove it, then? BTW I think your rewrite will strip query strings and
stuff like that. Maybe you just want RedirectPermanent instead of
Rewrite(Cond|Rule)?
Ladies and
First, thanks once again, Mr. Schultz, for getting back to me.
I noticed something rather promising: it seems that maxThreads for the
Port 443 connector were set at 150 for System "A" (problem box), but 400
for System "J" (box that's quite happy).
I've restarted Tomcat with the maxThreads
This is related to my query (thanks, Mr. Gregg) about "Tenured SOA."
It seems that on one of our customer installations, our webapp gets into
a state of running very slowly, and the dedicated subsystem it's running
in is showing massive levels of page-faulting.
I've compared the GC stats of
In at least two of our Tomcat installations, the Server Status page of
Manager is showing "tenured-SOA" around 3G, while the other pools are
showing much lower. What exactly *is* "tenured-SOA," and should this be
cause for alarm?
--
JHHL
1 - 100 of 381 matches
Mail list logo
