[Bug 63824] Http11Processor does not compare Connection header value case-insensitively

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63824

--- Comment #4 from Michael Osipov  ---
(In reply to Mark Thomas from comment #3)
> (In reply to Michael Osipov from comment #2)
> > As per defition, only one token is allowed,
> > so "close, close2" ist not valid.
> 
> "1#connection-option" means "1 or more, comma separated" so there is work to
> do here.

Arg, thanks. I do have trouble sometimes reading RFC BNF properly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63852] ServerInfo.java discloses server-version ignoring settings from server.xml

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63852

--- Comment #13 from Christopher Schultz  ---
(In reply to Ralf Hauser from comment #9)
> Every script kiddie pen tester will complain about it.

FTFY

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63824] Http11Processor does not compare Connection header value case-insensitively

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63824

--- Comment #3 from Mark Thomas  ---
(In reply to Michael Osipov from comment #2)

>Connection options are case-insensitive.

Thanks. I missed that statement below the formal grammar.

> As per defition, only one token is allowed,
> so "close, close2" ist not valid.

"1#connection-option" means "1 or more, comma separated" so there is work to do
here.

Still need to look into parsing options to see what the performance
implications of doing this "properly" are.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63824] Http11Processor does not compare Connection header value case-insensitively

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63824

--- Comment #2 from Michael Osipov  ---
https://tools.ietf.org/html/rfc7230#section-6.1 says:


   The Connection header field's value has the following grammar:

 Connection= 1#connection-option
 connection-option = token

   Connection options are case-insensitive.

As for the substring part:

"close2" token is not "close". As per defition, only one token is allowed, so
"close, close2" ist not valid.

I see this as a valid point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63824] Http11Processor does not compare Connection header value case-insensitively

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63824

--- Comment #1 from Mark Thomas  ---
HTTP header values are case sensitive (HTTP header names are insensitive). Both
RFC 2616 and RFC 7230 define the relevant token as "close" so the current case
sensitive comparison is correct.

The current code also assumes "close" is the entire header value. My reading of
the spec does not support that although I can't think of anything else that
would be present.

The worst that could happen is that the "close" token would be added twice
which, apart from the extra bandwidth, should not be an issue. I want to look
into the performance implications of parsing this "properly" but I am leaning
towards WONTFIX at this point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist

2019-10-16 Thread Mark Thomas
On 12/10/2019 00:03, Phil Steitz wrote:
> How about adding the DBCP unit tests to the source tree?  I suspect some
> would have failed due to this change.  If others think this is a good
> idea, I could take a stab at genericising them and creating a PR to add
> them.

+1

I'd suggest several commits. Something like:

- Copy latest 1.x from Commons
- Fix package naming issues
- Fix any running issues
- Fix warnings (inc. generics)

That way it should be easy to trace what changed from Commons and why.
The exact detail of how the changes are split between commits is not
important. It is the easy traceability that matters.

Mark


> 
> On 10/11/19 3:31 PM, bugzi...@apache.org wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=63833
>>
>> Phil Steitz  changed:
>>
>>     What    |Removed |Added
>> 
>>
>>   OS|    |All
>>
>> --- Comment #2 from Phil Steitz  ---
>> This is a regression from the generics conversion in
>> PoolableConnectionFactory.
>>
>> The original DBCP 1.x code effectively null-checked the object to be
>> destroyed:
>>  public void destroyObject(Object obj) throws Exception {
>>  if(obj instanceof PoolableConnection) {
>>  ((PoolableConnection)obj).reallyClose();
>>  }
>>
>> Removing the instanceOf check makes NPE possible:
>>  public void destroyObject(PoolableConnection obj) throws Exception {
>>  obj.reallyClose();
>>  }
>>
>> Solution is to add an explicit null check in destroyObject.
>>
>> Similar changes should be made to activate, passivate, validate methods.
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [VOTE] Private branches in the official Tomcat git repository

2019-10-16 Thread Mark Thomas
On 11/10/2019 15:20, Rémy Maucherat wrote:
> Hi,
> 
> This vote is to regulate the use of branches in the official Tomcat
> repository beyond branches that are approved by the community such as
> 8.5.x and 7.0.x. It is possible to do development in private branches
> directly in the official Tomcat repository, as an alternative to using
> forks and pull requests.
> 
> Should private branches be allowed in the official Tomcat git repository ?
> [ ] Yes
> [X] No

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63820] Install with JDK13 is not working

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63820

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED
 OS||All

--- Comment #1 from Mark Thomas  ---
tomcat-locate-java.sh is not part of the Tomcat distribution provided by the
ASF. You need to raise this bug with whoever provided that file - probably the
maintainer of the Linux distribution you are using.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63815] Expansion of JAVA_OPTS in catalina.sh containing '*' stops startup on linux

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63815

--- Comment #7 from Mark Thomas  ---
(In reply to Konstantin Kolinko from comment #2)

> Please note that on the last step (when invoking a java executable) the
> JAVA_OPTS must produce several separate command line arguments: java expects
> that each -D is passed as a separate command-line argument. As such,
> JAVA_OPTS cannot be quoted there.

I've confirmed that the above is not a concern. The arguments are passed
correct when that use of JAVA_OPTS is quoted. The quoting simply prevents the
expansion of * and strips new lines.

I have a patch locally that applies the quoting fix to JAVA_OPTS and
CATALINA_OPTS in all affected shell scripts.

I'm still leaning towards applying this fix without the removal of newlines and
noting the change of behaviour in the change log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[tomcat] branch 7.0.x updated: Fix typo

2019-10-16 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new af963c6  Fix typo
af963c6 is described below

commit af963c65d6692dcfd09be688ffc4f6eb671b8cc9
Author: Mark Thomas 
AuthorDate: Wed Oct 16 13:38:04 2019 +0100

Fix typo
---
 test/org/apache/catalina/core/TestAsyncContextStateChanges.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/org/apache/catalina/core/TestAsyncContextStateChanges.java 
b/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
index 836af28..b9fce86 100644
--- a/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
+++ b/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
@@ -63,7 +63,7 @@ public class TestAsyncContextStateChanges extends 
TomcatBaseTest {
 if (endTiming == EndTiming.THREAD_BEFORE_EXIT && 
asyncEnd.isError()) {
 // Skip these tests for Tomcat 7 as they deadlock due to
 // the write on the non-container thread being unable to
-// progress until Servlet.service() exists since both
+// progress until Servlet.service() exits since both
 // require a lock on the socket.
 // Note: Connector refactoring in 8.5.x onwards has removed
 //   this limitation


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[tomcat] branch 7.0.x updated: Restore the necessary syncs for correct async processing,

2019-10-16 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 91aa7e8  Restore the necessary syncs for correct async processing,
91aa7e8 is described below

commit 91aa7e888c64e6aa4c5bf1625024774dbe8f843e
Author: Mark Thomas 
AuthorDate: Wed Oct 16 12:03:44 2019 +0100

Restore the necessary syncs for correct async processing,

Disable the tests that deadlock due to the limitations of the 7.0.x
implementation. These limitations are unlikely to occur in real
applications. They require latches to attempt to force a specific
processing order.

Add code comments for the benefit of future maintainers.
---
 java/org/apache/tomcat/util/net/AprEndpoint.java   | 59 --
 java/org/apache/tomcat/util/net/JIoEndpoint.java   | 55 +++-
 .../core/TestAsyncContextStateChanges.java |  9 
 3 files changed, 71 insertions(+), 52 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index 10f1eb9..24014d4 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -975,33 +975,38 @@ public class AprEndpoint extends AbstractEndpoint {
 public void processSocketAsync(SocketWrapper socket,
 SocketStatus status) {
 try {
-if (waitingRequests.remove(socket)) {
-SocketProcessor proc = new SocketProcessor(socket, status);
-ClassLoader loader = 
Thread.currentThread().getContextClassLoader();
-try {
-//threads should not be created by the webapp classloader
-if (Constants.IS_SECURITY_ENABLED) {
-PrivilegedAction pa = new PrivilegedSetTccl(
-getClass().getClassLoader());
-AccessController.doPrivileged(pa);
-} else {
-Thread.currentThread().setContextClassLoader(
-getClass().getClassLoader());
-}
-Executor executor = getExecutor();
-if (executor == null) {
-log.warn(sm.getString("endpoint.warn.noExector",
-socket, status));
-return;
-} else {
-executor.execute(proc);
-}
-} finally {
-if (Constants.IS_SECURITY_ENABLED) {
-PrivilegedAction pa = new 
PrivilegedSetTccl(loader);
-AccessController.doPrivileged(pa);
-} else {
-Thread.currentThread().setContextClassLoader(loader);
+// Sync is necessary to ensure that the original processing thread
+// has placed the socket in waitingRequests before the dispatching
+// thread tries to use it.
+synchronized (socket) {
+if (waitingRequests.remove(socket)) {
+SocketProcessor proc = new SocketProcessor(socket, status);
+ClassLoader loader = 
Thread.currentThread().getContextClassLoader();
+try {
+//threads should not be created by the webapp 
classloader
+if (Constants.IS_SECURITY_ENABLED) {
+PrivilegedAction pa = new PrivilegedSetTccl(
+getClass().getClassLoader());
+AccessController.doPrivileged(pa);
+} else {
+Thread.currentThread().setContextClassLoader(
+getClass().getClassLoader());
+}
+Executor executor = getExecutor();
+if (executor == null) {
+log.warn(sm.getString("endpoint.warn.noExector",
+socket, status));
+return;
+} else {
+executor.execute(proc);
+}
+} finally {
+if (Constants.IS_SECURITY_ENABLED) {
+PrivilegedAction pa = new 
PrivilegedSetTccl(loader);
+AccessController.doPrivileged(pa);
+} else {
+
Thread.currentThread().setContextClassLoader(loader);
+}
 }
 }
 }
diff --git a/java/org/apache/tomcat/util/net/JIoEndpoint.java 
b/java/org/apache/tomcat/util/net/JIoEndpoint.java
index 

[GitHub] [tomcat] jgallimore opened a new pull request #214: Avoid reusing a processor from a request that has timed out

2019-10-16 Thread GitBox
jgallimore opened a new pull request #214: Avoid reusing a processor from a 
request that has timed out
URL: https://github.com/apache/tomcat/pull/214
 
 
   When a async request times out, this change will stop the associated 
processor from being added back to the pool for re-use.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[GitHub] [tomcat] jgallimore opened a new pull request #213: Avoid reusing a processor from a request that has timed out

2019-10-16 Thread GitBox
jgallimore opened a new pull request #213: Avoid reusing a processor from a 
request that has timed out
URL: https://github.com/apache/tomcat/pull/213
 
 
   When a async request times out, this change will stop the associated 
processor from being added back to the pool for re-use.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63832] Unable to stop because WebappClassLoaderBase.checkThreadLocalMapForLeaks can't load class(class from deployed aplication - probably undeployed)

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63832

Rafał Gała  changed:

   What|Removed |Added

 CC||rafal.g...@ingbank.pl

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[tomcat] branch 7.0.x updated: Temporary fix. Deadlock in the recently added async state tests

2019-10-16 Thread markt
This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new b6bba7b  Temporary fix. Deadlock in the recently added async state 
tests
b6bba7b is described below

commit b6bba7b9b364dad5f740042f0a6252a14eb0016a
Author: Mark Thomas 
AuthorDate: Wed Oct 16 10:05:42 2019 +0100

Temporary fix. Deadlock in the recently added async state tests

Removing this sync fixes the deadlock but re-introduces bug 49884. On
the basis that a 10s delay is better than a deadlock I am applying
this temporary fix (mainly to allow the CI to complete) while I
investigate a solution that creates neither delay nor deadlock.
---
 java/org/apache/tomcat/util/net/AprEndpoint.java | 56 
 1 file changed, 27 insertions(+), 29 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index 4d8fd25..10f1eb9 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -975,35 +975,33 @@ public class AprEndpoint extends AbstractEndpoint {
 public void processSocketAsync(SocketWrapper socket,
 SocketStatus status) {
 try {
-synchronized (socket) {
-if (waitingRequests.remove(socket)) {
-SocketProcessor proc = new SocketProcessor(socket, status);
-ClassLoader loader = 
Thread.currentThread().getContextClassLoader();
-try {
-//threads should not be created by the webapp 
classloader
-if (Constants.IS_SECURITY_ENABLED) {
-PrivilegedAction pa = new PrivilegedSetTccl(
-getClass().getClassLoader());
-AccessController.doPrivileged(pa);
-} else {
-Thread.currentThread().setContextClassLoader(
-getClass().getClassLoader());
-}
-Executor executor = getExecutor();
-if (executor == null) {
-log.warn(sm.getString("endpoint.warn.noExector",
-socket, status));
-return;
-} else {
-executor.execute(proc);
-}
-} finally {
-if (Constants.IS_SECURITY_ENABLED) {
-PrivilegedAction pa = new 
PrivilegedSetTccl(loader);
-AccessController.doPrivileged(pa);
-} else {
-
Thread.currentThread().setContextClassLoader(loader);
-}
+if (waitingRequests.remove(socket)) {
+SocketProcessor proc = new SocketProcessor(socket, status);
+ClassLoader loader = 
Thread.currentThread().getContextClassLoader();
+try {
+//threads should not be created by the webapp classloader
+if (Constants.IS_SECURITY_ENABLED) {
+PrivilegedAction pa = new PrivilegedSetTccl(
+getClass().getClassLoader());
+AccessController.doPrivileged(pa);
+} else {
+Thread.currentThread().setContextClassLoader(
+getClass().getClassLoader());
+}
+Executor executor = getExecutor();
+if (executor == null) {
+log.warn(sm.getString("endpoint.warn.noExector",
+socket, status));
+return;
+} else {
+executor.execute(proc);
+}
+} finally {
+if (Constants.IS_SECURITY_ENABLED) {
+PrivilegedAction pa = new 
PrivilegedSetTccl(loader);
+AccessController.doPrivileged(pa);
+} else {
+Thread.currentThread().setContextClassLoader(loader);
 }
 }
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: [tomcat] 04/04: Remove sync that triggers deadlock with BZ 63816 test case

2019-10-16 Thread Mark Thomas
On 14/10/2019 17:58, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> markt pushed a commit to branch 7.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> commit fe65d4c1aac1759e99befe417afde51dded567b5
> Author: Mark Thomas 
> AuthorDate: Mon Oct 14 17:51:56 2019 +0100
> 
> Remove sync that triggers deadlock with BZ 63816 test case

Hmm.

The same deadlock exists with APR.

However, the sync appears to be required to prevent bug 49884.

It looks like I need to spend some more time with the async code. I'll
remove the sync for now on the grounds that a deadlock is worse than a
10s delay but my intention is that that is only a temporary fix.

Mark



> 
> I haven't been able to re-create the test failure on Linux that
> promoted the adding of this sync. It is sufficiently long ago
> that other refactoring may have provided an alternative fix.
> ---
>  java/org/apache/tomcat/util/net/JIoEndpoint.java | 52 
> 
>  1 file changed, 25 insertions(+), 27 deletions(-)
> 
> diff --git a/java/org/apache/tomcat/util/net/JIoEndpoint.java 
> b/java/org/apache/tomcat/util/net/JIoEndpoint.java
> index 166640a..024de03 100644
> --- a/java/org/apache/tomcat/util/net/JIoEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/JIoEndpoint.java
> @@ -559,33 +559,31 @@ public class JIoEndpoint extends 
> AbstractEndpoint {
>  public void processSocketAsync(SocketWrapper socket,
>  SocketStatus status) {
>  try {
> -synchronized (socket) {
> -if (waitingRequests.remove(socket)) {
> -SocketProcessor proc = new 
> SocketProcessor(socket,status);
> -ClassLoader loader = 
> Thread.currentThread().getContextClassLoader();
> -try {
> -//threads should not be created by the webapp 
> classloader
> -if (Constants.IS_SECURITY_ENABLED) {
> -PrivilegedAction pa = new 
> PrivilegedSetTccl(
> -getClass().getClassLoader());
> -AccessController.doPrivileged(pa);
> -} else {
> -Thread.currentThread().setContextClassLoader(
> -getClass().getClassLoader());
> -}
> -// During shutdown, executor may be null - avoid NPE
> -if (!running) {
> -return;
> -}
> -getExecutor().execute(proc);
> -//TODO gotta catch RejectedExecutionException and 
> properly handle it
> -} finally {
> -if (Constants.IS_SECURITY_ENABLED) {
> -PrivilegedAction pa = new 
> PrivilegedSetTccl(loader);
> -AccessController.doPrivileged(pa);
> -} else {
> -
> Thread.currentThread().setContextClassLoader(loader);
> -}
> +if (waitingRequests.remove(socket)) {
> +SocketProcessor proc = new SocketProcessor(socket,status);
> +ClassLoader loader = 
> Thread.currentThread().getContextClassLoader();
> +try {
> +//threads should not be created by the webapp classloader
> +if (Constants.IS_SECURITY_ENABLED) {
> +PrivilegedAction pa = new PrivilegedSetTccl(
> +getClass().getClassLoader());
> +AccessController.doPrivileged(pa);
> +} else {
> +Thread.currentThread().setContextClassLoader(
> +getClass().getClassLoader());
> +}
> +// During shutdown, executor may be null - avoid NPE
> +if (!running) {
> +return;
> +}
> +getExecutor().execute(proc);
> +//TODO gotta catch RejectedExecutionException and 
> properly handle it
> +} finally {
> +if (Constants.IS_SECURITY_ENABLED) {
> +PrivilegedAction pa = new 
> PrivilegedSetTccl(loader);
> +AccessController.doPrivileged(pa);
> +} else {
> +Thread.currentThread().setContextClassLoader(loader);
>  }
>  }
>  }
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: 

[tomcat] branch 7.0.x updated: Fix BZ number

2019-10-16 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new aaef01d  Fix BZ number
aaef01d is described below

commit aaef01dd1046fe0beb816da82def0d373476d3b6
Author: remm 
AuthorDate: Wed Oct 16 11:22:11 2019 +0200

Fix BZ number
---
 webapps/docs/changelog.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 3f10e31..a48d4bd 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -63,7 +63,7 @@
   
 
   
-63765: Properly mark container as FAILED when a JVM error
+63832: Properly mark container as FAILED when a JVM error
 occurs on stop. (remm)
   
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[tomcat] branch 8.5.x updated: Fix BZ number

2019-10-16 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 57c6917  Fix BZ number
57c6917 is described below

commit 57c69179dfb6405671de65ae62efdb3764f8d22f
Author: remm 
AuthorDate: Wed Oct 16 11:19:06 2019 +0200

Fix BZ number
---
 webapps/docs/changelog.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index f3b6a80..3d083d3 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -48,7 +48,7 @@
   
 
   
-63765: Properly mark container as FAILED when a JVM error
+63832: Properly mark container as FAILED when a JVM error
 occurs on stop. (remm)
   
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[tomcat] branch master updated: Fix BZ number

2019-10-16 Thread remm
This is an automated email from the ASF dual-hosted git repository.

remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 339f910  Fix BZ number
339f910 is described below

commit 339f910ddd677cd2b48d86b59f5c7ad4d0ac4685
Author: remm 
AuthorDate: Wed Oct 16 11:19:06 2019 +0200

Fix BZ number
---
 webapps/docs/changelog.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 6eb0435..f3e161c 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -52,7 +52,7 @@
 path separator, so wrap using an IOException. (remm)
   
   
-63765: Properly mark container as FAILED when a JVM error
+63832: Properly mark container as FAILED when a JVM error
 occurs on stop. (remm)
   
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63852] ServerInfo.java discloses server-version ignoring settings from server.xml

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63852

--- Comment #12 from Michael Osipov  ---
(In reply to Ralf Hauser from comment #9)
> Every penetration tester will complain about it.
> If they can be made happy in one go, that would be great.
> In the current setup, they in most cases will have two points to raise...

Same recommended me to upgrade to 9.0.x from 8.5.x because it is the "best"
available version -- nonsense.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63852] ServerInfo.java discloses server-version ignoring settings from server.xml

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63852

--- Comment #11 from Michael Osipov  ---
(In reply to Mark Thomas from comment #8)
> (In reply to Ralf Hauser from comment #5)
> >showServerInfo=false
> > achieves a similar goal, but why not be consistent with the "server"
> > attribute of server.xml ?
> 
> There are some subtle differences.
> 
> What there might be a case for is if "server" is explicitly set on the
> Connector then use the same value in the ErrorReportValve although I'm not
> sure the added code/complexity is worth the benefit.

I'd be against such high coupling of components...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 63852] ServerInfo.java discloses server-version ignoring settings from server.xml

2019-10-16 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63852

--- Comment #10 from Michael Osipov  ---
(In reply to Mark Thomas from comment #7)
> The tone of some of the comments on this issue is getting a little
> unfriendly.
> 
> I'd ask that everyone remind themselves of the ASF code of conduct -
> particularly guideline 2:
> 
> "Be empathetic, welcoming, friendly, and patient."
> 
> Thanks.

+1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org