[Bug 63966] Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

--- Comment #3 from Christopher Schultz  ---
(In reply to Mark Thomas from comment #1)
> The response is correctly signalled as ISO-8859-1 encoded and is spec
> compliant.

How long before we stuff the response text into a localized properties file and
have to chance it to UTF-8 to make it work? Perhaps /we/ should bend rather
than the bug reporter?

-- 
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: Tomcat next and Jakarta EE

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 11:15 PM Mark Thomas  wrote:

> Hi,
>
> Work over at Eclipse is starting on Jakarta EE 9 where the significant
> change will be the renaming of javax.* to jakarta.*
>
> In parallel, I'd like to start implementing those changes in Tomcat. As
> I am still unsure of exactly where I want end up (I have a few ideas I
> want to experiment with) I plan to do this in a branch of my public fork
> and provide a PR for master when I have a firmer idea of what this will
> look like.
>
> In the meantime, I think we need to start discussing - at least in
> outline - how we will support Java EE and Jakarta EE going forward.
>
> Here is a not very well thought out starter.
>
> Current status
>  7.0.x : Continues to support Java EE 6
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
>
> Step 1 (ASAP)
> =
> No change:
>  7.0.x : Continues to support Java EE 6
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
> Add:
>  9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
>  Make clear to users 9.5.x will EOL as soon as 9.6.x (see later)
>  is stable
>
> Step 2 (Jakarta EE 9 - April 2020?)
> ===
> Announce EOL:
>  7.0.x : Announce EOL around time of first stable 10.0.x release.
> No change:
>  8.5.x : Continues to support Java EE 7
>  9.0.x : Continues to support Java EE 8
>  9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
> Add:
> 10.0.x : Identical to 9.5.x but supports Jakarta EE 9
>
> Keep 10.0.x and 9.5.x in step part from Java EE / Jakarta EE API
>
>
> Step 3 (Jakarta EE 10)
> ==
> Announce EOL:
>  8.5.x : Announce EOL around time of first stable 11.0.x release.
>  9.5.x : Announce immediate EOL with first stable 11.0.x release.
> No change:
>  9.0.x : Continues to support Java EE 8
> 10.0.x : Identical to 9.5.x but supports Jakarta EE 9
> Add
>  9.6.x : Supports Java EE 8 and includes Tomcat API changes in 11.0.x
> 11.0.x : Supports Jakarta EE 10
>
> And so on.
>
> We eventually end up with:
> Tomcat X supporting Jakarta EE X-1
> Tomcat X-1 supporting Jakarta EE X-2
> Tomcat X-2 supporting Jakarta EE X-3
> And Tomcat 9.Y supporting Java EE 8 with the same Tomcat API as Tomcat X
>
>
> What I am trying to do with this plan is maintain the 3 major versions
> in parallel but add ongoing support for Java EE 8 tied to the latest
> Tomcat major release.
>
> An alternative would be to maintain 9.0.x for as long as there is demand.
>
> Thoughts? Alternative approaches?
>

Well, it sounds pretty good to me but the numbers are off and it's going to
be very very confusing. It pretty much has to be:
Tomcat X supporting Jakarta EE X
Tomcat X-1 supporting Jakarta EE X-1
Tomcat X-2 supporting Jakarta EE X-2
And Tomcat 9.X supporting Java EE 8 with the same Tomcat API as Tomcat X [I
understand the rationale for this to be able to achieve very long term
support - and I expect the API changes will likely be rather small anyway
-, for example 8.5 and 9.0 have diverged too much to keep 8.5 more stable,
while if we had a 8.6 "trunk" to simply replace it eventually we could have
kept in strict sync with 9.0]

The only problem then (but it's a big one) is to accommodate the Tomcat
"10" supporting Jakarta EE 9 somewhere. Maybe 9.9 can be used for that but
it will still pollute a bit the 9.x message, it could be labelled as a
"Jakarta preview" or something maybe. Jakarta EE 9 is a useless release
anyway, nobody will use it and that Tomcat could almost be EOLed
immediately after a Jakarta EE 10 release.

Rémy

[Bug 63970] java.lang.ClassCastException: org.apache.catalina.webresources.CachedResource$CachedResourceURLConnection cannot be cast to java.net.JarURLConnection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63970

--- Comment #4 from Mark Thomas  ---
OK. The upload is complete. The dev build is here:
http://people.apache.org/~markt/dev/v9.0.30-dev/

If you could download, test and report back that would be very helpful.

Note:
- this is NOT an official release
- this is NOT for production use
- this is ONLY for testing this bug
- please don't blame me if your server catches fire during testing ;)

(Sorry to go on about this but ASF releases have various bits of QA and legal
machinery behind them whereas test/dev builds like this don't and we need to
make sure folks reading this understand there is a difference.)

-- 
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 63970] java.lang.ClassCastException: org.apache.catalina.webresources.CachedResource$CachedResourceURLConnection cannot be cast to java.net.JarURLConnection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63970

--- Comment #3 from Mark Thomas  ---
Don't worry - I've already fixed it. I was just waiting for a couple of test
builds to upload so I could point you towards them for testing. I'd like to try
and avoid further regressions in the next round of releases.

-- 
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 next and Jakarta EE

[Mark Thomas]

Hi,

Work over at Eclipse is starting on Jakarta EE 9 where the significant
change will be the renaming of javax.* to jakarta.*

In parallel, I'd like to start implementing those changes in Tomcat. As
I am still unsure of exactly where I want end up (I have a few ideas I
want to experiment with) I plan to do this in a branch of my public fork
and provide a PR for master when I have a firmer idea of what this will
look like.

In the meantime, I think we need to start discussing - at least in
outline - how we will support Java EE and Jakarta EE going forward.

Here is a not very well thought out starter.

Current status
 7.0.x : Continues to support Java EE 6
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8

Step 1 (ASAP)
=
No change:
 7.0.x : Continues to support Java EE 6
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8
Add:
 9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
 Make clear to users 9.5.x will EOL as soon as 9.6.x (see later)
 is stable

Step 2 (Jakarta EE 9 - April 2020?)
===
Announce EOL:
 7.0.x : Announce EOL around time of first stable 10.0.x release.
No change:
 8.5.x : Continues to support Java EE 7
 9.0.x : Continues to support Java EE 8
 9.5.x : Supports Java EE 8 with Tomcat API changes planned for 10.0.x
Add:
10.0.x : Identical to 9.5.x but supports Jakarta EE 9

Keep 10.0.x and 9.5.x in step part from Java EE / Jakarta EE API


Step 3 (Jakarta EE 10)
==
Announce EOL:
 8.5.x : Announce EOL around time of first stable 11.0.x release.
 9.5.x : Announce immediate EOL with first stable 11.0.x release.
No change:
 9.0.x : Continues to support Java EE 8
10.0.x : Identical to 9.5.x but supports Jakarta EE 9
Add
 9.6.x : Supports Java EE 8 and includes Tomcat API changes in 11.0.x
11.0.x : Supports Jakarta EE 10

And so on.

We eventually end up with:
Tomcat X supporting Jakarta EE X-1
Tomcat X-1 supporting Jakarta EE X-2
Tomcat X-2 supporting Jakarta EE X-3
And Tomcat 9.Y supporting Java EE 8 with the same Tomcat API as Tomcat X


What I am trying to do with this plan is maintain the 3 major versions
in parallel but add ongoing support for Java EE 8 tied to the latest
Tomcat major release.

An alternative would be to maintain 9.0.x for as long as there is demand.

Thoughts? Alternative approaches?

Mark

-
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 https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast JAR conns

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt 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 c7e660d  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast 
JAR conns
c7e660d is described below

commit c7e660d7b43c190847b7c3c19255876ac0f09de5
Author: Mark Thomas 
AuthorDate: Wed Nov 27 19:37:47 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast JAR conns

Correct a regression in the static resource caching changes introduced
in 9.0.28. Connections to URLs obtained for JAR resources could not be
cast to JarURLConnection.
---
 .../catalina/webresources/CachedResource.java  | 87 +-
 .../catalina/webresources/TestCachedResource.java  | 27 +++
 webapps/docs/changelog.xml |  5 ++
 3 files changed, 115 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/catalina/webresources/CachedResource.java 
b/java/org/apache/catalina/webresources/CachedResource.java
index 6b3e615..ec21f40 100644
--- a/java/org/apache/catalina/webresources/CachedResource.java
+++ b/java/org/apache/catalina/webresources/CachedResource.java
@@ -19,12 +19,14 @@ package org.apache.catalina.webresources;
 import java.io.ByteArrayInputStream;
 import java.io.IOException;
 import java.io.InputStream;
+import java.net.JarURLConnection;
 import java.net.MalformedURLException;
 import java.net.URL;
 import java.net.URLConnection;
 import java.net.URLStreamHandler;
 import java.security.Permission;
 import java.security.cert.Certificate;
+import java.util.jar.JarFile;
 import java.util.jar.Manifest;
 
 import org.apache.catalina.WebResource;
@@ -358,8 +360,11 @@ public class CachedResource implements WebResource {
 return null;
 }
 try {
-return new URL(null, resourceURL.toExternalForm(),
-new CachedResourceURLStreamHandler(resourceURL, root, 
webAppPath, usesClassLoaderResources));
+CachedResourceURLStreamHandler handler =
+new CachedResourceURLStreamHandler(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+URL result = new URL(null, resourceURL.toExternalForm(), handler);
+handler.setAssociatedURL(result);
+return result;
 } catch (MalformedURLException e) {
 log.error(sm.getString("cachedResource.invalidURL", 
resourceURL.toExternalForm()), e);
 return null;
@@ -413,6 +418,8 @@ public class CachedResource implements WebResource {
 private final String webAppPath;
 private final boolean usesClassLoaderResources;
 
+private URL associatedURL = null;
+
 public CachedResourceURLStreamHandler(URL resourceURL, StandardRoot 
root, String webAppPath,
 boolean usesClassLoaderResources) {
 this.resourceURL = resourceURL;
@@ -421,13 +428,21 @@ public class CachedResource implements WebResource {
 this.usesClassLoaderResources = usesClassLoaderResources;
 }
 
+protected void setAssociatedURL(URL associatedURL) {
+this.associatedURL = associatedURL;
+}
+
 @Override
 protected URLConnection openConnection(URL u) throws IOException {
 // This deliberately uses ==. If u isn't the URL object this
 // URLStreamHandler was constructed for we do not want to use this
 // URLStreamHandler to create a connection.
-if (u == resourceURL) {
-return new CachedResourceURLConnection(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+if (associatedURL != null && u == associatedURL) {
+if ("jar".equals(associatedURL.getProtocol())) {
+return new CachedResourceJarURLConnection(resourceURL, 
root, webAppPath, usesClassLoaderResources);
+} else {
+return new CachedResourceURLConnection(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+}
 } else {
 // The stream handler has been inherited by a URL that was
 // constructed from a cache URL. We need to break that link.
@@ -438,6 +453,9 @@ public class CachedResource implements WebResource {
 }
 
 
+/*
+ * Keep this in sync with CachedResourceJarURLConnection.
+ */
 private static class CachedResourceURLConnection extends URLConnection {
 
 private final StandardRoot root;
@@ -489,4 +507,65 @@ public class CachedResource implements WebResource {
 return root.getResource(webAppPath, false, 
usesClassLoaderResources);
 }
 }
+
+
+/*
+ * Keep this in sync with CachedResourceURLConnection.
+ */
+private static class CachedResourceJarURLConnection extends 
JarURLConnection {
+
+private final 

[Bug 63970] java.lang.ClassCastException: org.apache.catalina.webresources.CachedResource$CachedResourceURLConnection cannot be cast to java.net.JarURLConnection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63970

--- Comment #2 from Dmitry Treskunov  ---
Thanks for the answer. Sorry, I didn't quite understand, does it mean that you
are not going to fix it?

-- 
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 master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast JAR conns

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt 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 709b629  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast 
JAR conns
709b629 is described below

commit 709b6295087a0bfb5576ffb2acb7fcb5896a6f1c
Author: Mark Thomas 
AuthorDate: Wed Nov 27 19:37:47 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63970 cast JAR conns

Correct a regression in the static resource caching changes introduced
in 9.0.28. Connections to URLs obtained for JAR resources could not be
cast to JarURLConnection.
---
 .../catalina/webresources/CachedResource.java  | 87 +-
 .../catalina/webresources/TestCachedResource.java  | 27 +++
 webapps/docs/changelog.xml |  5 ++
 3 files changed, 115 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/catalina/webresources/CachedResource.java 
b/java/org/apache/catalina/webresources/CachedResource.java
index 6b3e615..ec21f40 100644
--- a/java/org/apache/catalina/webresources/CachedResource.java
+++ b/java/org/apache/catalina/webresources/CachedResource.java
@@ -19,12 +19,14 @@ package org.apache.catalina.webresources;
 import java.io.ByteArrayInputStream;
 import java.io.IOException;
 import java.io.InputStream;
+import java.net.JarURLConnection;
 import java.net.MalformedURLException;
 import java.net.URL;
 import java.net.URLConnection;
 import java.net.URLStreamHandler;
 import java.security.Permission;
 import java.security.cert.Certificate;
+import java.util.jar.JarFile;
 import java.util.jar.Manifest;
 
 import org.apache.catalina.WebResource;
@@ -358,8 +360,11 @@ public class CachedResource implements WebResource {
 return null;
 }
 try {
-return new URL(null, resourceURL.toExternalForm(),
-new CachedResourceURLStreamHandler(resourceURL, root, 
webAppPath, usesClassLoaderResources));
+CachedResourceURLStreamHandler handler =
+new CachedResourceURLStreamHandler(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+URL result = new URL(null, resourceURL.toExternalForm(), handler);
+handler.setAssociatedURL(result);
+return result;
 } catch (MalformedURLException e) {
 log.error(sm.getString("cachedResource.invalidURL", 
resourceURL.toExternalForm()), e);
 return null;
@@ -413,6 +418,8 @@ public class CachedResource implements WebResource {
 private final String webAppPath;
 private final boolean usesClassLoaderResources;
 
+private URL associatedURL = null;
+
 public CachedResourceURLStreamHandler(URL resourceURL, StandardRoot 
root, String webAppPath,
 boolean usesClassLoaderResources) {
 this.resourceURL = resourceURL;
@@ -421,13 +428,21 @@ public class CachedResource implements WebResource {
 this.usesClassLoaderResources = usesClassLoaderResources;
 }
 
+protected void setAssociatedURL(URL associatedURL) {
+this.associatedURL = associatedURL;
+}
+
 @Override
 protected URLConnection openConnection(URL u) throws IOException {
 // This deliberately uses ==. If u isn't the URL object this
 // URLStreamHandler was constructed for we do not want to use this
 // URLStreamHandler to create a connection.
-if (u == resourceURL) {
-return new CachedResourceURLConnection(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+if (associatedURL != null && u == associatedURL) {
+if ("jar".equals(associatedURL.getProtocol())) {
+return new CachedResourceJarURLConnection(resourceURL, 
root, webAppPath, usesClassLoaderResources);
+} else {
+return new CachedResourceURLConnection(resourceURL, root, 
webAppPath, usesClassLoaderResources);
+}
 } else {
 // The stream handler has been inherited by a URL that was
 // constructed from a cache URL. We need to break that link.
@@ -438,6 +453,9 @@ public class CachedResource implements WebResource {
 }
 
 
+/*
+ * Keep this in sync with CachedResourceJarURLConnection.
+ */
 private static class CachedResourceURLConnection extends URLConnection {
 
 private final StandardRoot root;
@@ -489,4 +507,65 @@ public class CachedResource implements WebResource {
 return root.getResource(webAppPath, false, 
usesClassLoaderResources);
 }
 }
+
+
+/*
+ * Keep this in sync with CachedResourceURLConnection.
+ */
+private static class CachedResourceJarURLConnection extends 
JarURLConnection {
+
+private final 

[Bug 63970] java.lang.ClassCastException: org.apache.catalina.webresources.CachedResource$CachedResourceURLConnection cannot be cast to java.net.JarURLConnection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63970

--- Comment #1 from Mark Thomas  ---
Yes, this is caused by that commit.

The fix looks fairly simple but we are at the limit of what the current
implementation can reasonably do in terms of guaranteeing consistency. Chances
are you are going to end up accessing the resource directly, bypassing the
cache and running the risk of seeing inconsistent results. That said, the
chances of a resource inside a JAR changing should be a lot lower.

-- 
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: [tomcat] branch BZ-63681/8.5.x updated (6be96eb -> a0e8d49)

[Mark Thomas]

On 27/11/2019 18:24, Michael Osipov wrote:
> Am 2019-11-27 um 18:05 schrieb Rémy Maucherat:
>> On Wed, Nov 27, 2019 at 11:28 AM  wrote:
>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> michaelo pushed a change to branch BZ-63681/8.5.x
>>> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
>>>
>>
>> This branch is 100% unnecessary. Please delete it instead of keeping
>> spamming me (and others).
> 
> It is not, 8.5.x requires a different implementation of the issue.

I think the point is that a branch in your fork and then a PR is less
noisy than a branch in the main repo for the other committers.

Mark

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

Re: [tomcat] branch BZ-63681/8.5.x updated (6be96eb -> a0e8d49)

[Michael Osipov]

Am 2019-11-27 um 18:05 schrieb Rémy Maucherat:

On Wed, Nov 27, 2019 at 11:28 AM  wrote:


This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a change to branch BZ-63681/8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.



This branch is 100% unnecessary. Please delete it instead of keeping
spamming me (and others).


It is not, 8.5.x requires a different implementation of the issue.


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

[Bug 63948] MultipartFile upload big files over HTTP/2 broken

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63948

--- Comment #6 from Rodrigo Darti da Costa  ---
(In reply to Andy Wilkinson from comment #4)
> Rodrigo, you can customise the Http2Protocol by adding the following bean to
> your Spring Boot application:
> 
> @Bean
> public TomcatConnectorCustomizer http2ProtocolCustomizer() {
>   return (connector) -> {
> for (UpgradeProtocol upgradeProtocol: connector.findUpgradeProtocols()) {
>   if (upgradeProtocol instanceof Http2Protocol) {
> Http2Protocol http2Protocol = (Http2Protocol)upgradeProtocol;
> http2Protocol.setOverheadContinuationThreshold(0);
> http2Protocol.setOverheadDataThreshold(0);
> http2Protocol.setOverheadWindowUpdateThreshold(0);
>   }
> }
>   };
> }
> 
> With this bean in place in your sample application, I'm no longer able to
> reproduce the problem with curl 7.54.0 on macOS. With the hint from Mark
> that the problem may be client-specific, I also tried with curl 7.67.0 and
> the problem does not occur, even without the customization of the
> Http2Protocol.

Thx for all the help.

The error no longer occurs after deploying bean.

I am using the observable (subscribe) of angular to send the file, here is the
frameworks:

https://www.primefaces.org/primeng/#/fileupload

https://angular.io/guide/http

-- 
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 63859] AJP cping/cpong mode failing on Tomcat 9.x

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63859

--- Comment #22 from Mark Thomas  ---
The only thing that has changed as far as I know is Tomcat no longer always
does a blocking read after the CPing/CPong.

I still don't see how that could have caused the error though...

Could we give it until after the weekend to see? I'll be tagging the next set
of releases then. Meanwhile, I'll see if I can see how the blocking read could
trigger this.

-- 
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 8.5.x updated: Fix buffering strategy inconsistency

[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 9fec9f1  Fix buffering strategy inconsistency
9fec9f1 is described below

commit 9fec9f1189ab1a8220a17fcdc08c1a869f8ab831
Author: remm 
AuthorDate: Wed Nov 27 18:08:45 2019 +0100

Fix buffering strategy inconsistency

For now: buffer everything, write only when necessary.
---
 java/org/apache/tomcat/util/net/SocketWrapperBase.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/SocketWrapperBase.java 
b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
index 545d333..30d2d47 100644
--- a/java/org/apache/tomcat/util/net/SocketWrapperBase.java
+++ b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
@@ -597,7 +597,7 @@ public abstract class SocketWrapperBase {
 protected void writeNonBlockingInternal(ByteBuffer from) throws 
IOException {
 socketBufferHandler.configureWriteBufferForWrite();
 transfer(from, socketBufferHandler.getWriteBuffer());
-while (from.hasRemaining() && 
!socketBufferHandler.isWriteBufferWritable()) {
+while (from.hasRemaining()) {
 doWrite(false);
 if (socketBufferHandler.isWriteBufferWritable()) {
 socketBufferHandler.configureWriteBufferForWrite();


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

[tomcat] branch master updated: Fix buffering strategy inconsistency

[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 f2376d4  Fix buffering strategy inconsistency
f2376d4 is described below

commit f2376d49f90cf9ff5181ee9b77c0f6cc6923a4ef
Author: remm 
AuthorDate: Wed Nov 27 18:08:45 2019 +0100

Fix buffering strategy inconsistency

For now: buffer everything, write only when necessary.
---
 java/org/apache/tomcat/util/net/SocketWrapperBase.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/SocketWrapperBase.java 
b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
index 9a2662f..22bcf87 100644
--- a/java/org/apache/tomcat/util/net/SocketWrapperBase.java
+++ b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
@@ -647,7 +647,7 @@ public abstract class SocketWrapperBase {
 protected void writeNonBlockingInternal(ByteBuffer from) throws 
IOException {
 socketBufferHandler.configureWriteBufferForWrite();
 transfer(from, socketBufferHandler.getWriteBuffer());
-while (from.hasRemaining() && 
!socketBufferHandler.isWriteBufferWritable()) {
+while (from.hasRemaining()) {
 doWrite(false);
 if (socketBufferHandler.isWriteBufferWritable()) {
 socketBufferHandler.configureWriteBufferForWrite();


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

[Bug 63969] Stackoverflow in JSF

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63969

Mark Thomas  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Mark Thomas  ---
I think this is fixed already. Can you try a 9.0.30 dev build from here and
report back?
http://people.apache.org/~markt/dev/v9.0.30-dev/

Note that is a dev build for testing only. It isn't an official release. Please
don't use it in production and please don't blame me if your server catches
fire when you run it ;)

-- 
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: Drop SocketWrapperBase.write(Non)BlockingDirect methods

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 5:35 PM Mark Thomas  wrote:

> On 27/11/2019 15:59, Rémy Maucherat wrote:
> > On Wed, Nov 27, 2019 at 4:51 PM Mark Thomas  > > wrote:
> >
> > I've been looking at the 9.0.x changes.
> >
> > What is clearer now (I think the differences were always there - just
> > harder to see with the more complex code) is that there are some
> minor
> > differences in behaviour when all of the following are true:
> > - the source buffer is emptied when it is copied to the socket buffer
> > - the socket buffer is full after the source buffer has been copied
> >
> > In some cases there will be an immediate write to the network. In
> other
> > cases the network write will wait until the next write to the socket
> > buffer or the next explicit flush.
> >
> > I think I prefer an immediate write in this scenario. WDYT to
> updating
> > (very carefully) all of the write methods to behave that way?
> >
> >
> > Ah personally I did prefer not writing that full buffer (unless the
> > source still has data, of course) on purpose since I considered not
> > doing IO reduced the likelihood to block on IO (or write 0 for non
> > blocking and having to use the poller). That's possible though if you
> > like it better.
>
> My preference for writing earlier is only a slight one. I'm more
> concerned that different methods take a different approach. Taking a
> closer look at that is on my TODO list but it isn't a priority for me at
> the moment.
>

I'll double check the inconsistency :)

writeBlocking writes after.
writeNonBlockingInternal has that  "&&
!socketBufferHandler.isWriteBufferWritable()" in the while loop that makes
the thing inconsistent, it is a leftover from the old code.
For now I'll fix that.

Rémy

Re: [DISCUSS] Remove org.apache.catalina.servlet4preview from 8.5.x

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 6:06 PM Mark Thomas  wrote:

> Hi all,
>
> The Servlet 4 preview API in 8.5.x has been deprecated for over a year.
> It was also inconsistent with the final Servlet 4.0 API until I fixed it
> in 8.5.49 although no-one complained about the inconsistency.
>
> I'd like to propose removing the code completely.
>
> I know this is an unusual thing to do in a point release - hence this
> discussion thread. My reasoning is:
>
> - Anyone who wants Servlet 4 will have moved to 9.0.x already
>
> - The servlet4preview has been deprecated for over a year
>
> - We warned that it would be removed from 8.5.x at some point when we
>   deprecated it.
>
> - If people were using it, they would have complained that the API was
>   wrong and no complaints were received. (At least I don't recall any.)
>
> - It adds unnecessary complexity to the 8.5.x code.
>
> - I like deleting code ;)
>

:)

>
> Thoughts?
>

+1, try it.

Rémy

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

[DISCUSS] Remove org.apache.catalina.servlet4preview from 8.5.x

[Mark Thomas]

Hi all,

The Servlet 4 preview API in 8.5.x has been deprecated for over a year.
It was also inconsistent with the final Servlet 4.0 API until I fixed it
in 8.5.49 although no-one complained about the inconsistency.

I'd like to propose removing the code completely.

I know this is an unusual thing to do in a point release - hence this
discussion thread. My reasoning is:

- Anyone who wants Servlet 4 will have moved to 9.0.x already

- The servlet4preview has been deprecated for over a year

- We warned that it would be removed from 8.5.x at some point when we
  deprecated it.

- If people were using it, they would have complained that the API was
  wrong and no complaints were received. (At least I don't recall any.)

- It adds unnecessary complexity to the 8.5.x code.

- I like deleting code ;)

Thoughts?

Mark

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

Re: [tomcat] branch BZ-63681/8.5.x updated (6be96eb -> a0e8d49)

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 11:28 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> michaelo pushed a change to branch BZ-63681/8.5.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git.
>

This branch is 100% unnecessary. Please delete it instead of keeping
spamming me (and others).

Rémy


>
>
>  discard 6be96eb  Frist draft
>  add ca38cf1  Fix indent
>  add 5c1699a  Deprecate org.apache.tomcat.util.compat.TLS and move its
> functionality to its only using lass org.apache.tomcat.util.net
> .TesterSupport.
>  add 831c6e1  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63753
> WS host header
>  add 07f3c37  Fix test failures caused by APR crash during shutdown
>  add b7ae3eb  Add release date for 8.5.46
>  add 6dae407  Revert "Fix test failures caused by APR crash during
> shutdown"
>  add 99e5ea8  Add Javadoc for the Common Annotation API
>  add 8b7ade1  Correct version number
>  add da37f36  https://bz.apache.org/bugzilla/show_bug.cgi?id=63759
> Uninstaller & UAC
>  add 4e984dc  Polish. Align spacing, remove svn (and cvs!) references
>  add c24a6ae  Align Java version references
>  add c8ddc6f  Update link to point to Java 7 javadoc
>  add ce4f6b7  Parameterise minimum Java version
>  add c9f3362  Fix xml source file that wasn't using expected version
> replacement
>  add 39bcbd0  Fix xml source file that wasn't using expected version
> replacement
>  add 993e80e  BZ63765: Try to unwrap first after handshake
>  add 3aba970  Fix test failures with APR/native.
>  add 5dda8bf  Fix incorrect default value of maxThreads in cluster
> receiver docs.
>  add 8c2f067  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63766
>  add d817d1e  Align with 9.0.x. Spacing, Javadoc
>  add 2a26382  Add throwOnFailure to LifecycleBase.
>  add 8fc21ef  Fix indent
>  add 0378b4b  Align Javadoc with 9.0.x
>  add 30f7e93  Align with 9.0.x. Mostly Javadoc with a little
> refactoring.
>  add 1b0c02c  Align with 9.0.x. Spacing.
>  add d9f4dd4  Align with 9.0.x - spacing
>  add 71deb4b  Align with 9.0.x - spacing, i18n
>  add f3c4438  Align with 9.0.x- spacing, l10n
>  add c9fda66  Align with 9.0.x
>  add 02bbd57  Align with 9.0.x spacing
>  add 845d972  Align with 9.0.x - spacing
>  add 8dbabe3  Fix alignment of start-up messages
>  add 74cd321  Fix open transaction after validation
>  add 98943df  Add logging
>  add a7e6a5d  Add logging
>  add 0bcf094  Try and detect bugs like BZ 63778
>  add 7c15360  Try and detect bugs like BZ 63778
>  add fa8de32  Fix typos
>  add cc85b6c  Fixes having an issue number are sorted by their number,
> ascending.
>  add 7637860  Remove unnecessary @SuppressWarnings
>  add 260133b  Remove unused code
>  add b5d2660  Prep fix for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
>  add c110bf8  Update to Commons Daemon 1.2.2
>  add 1de02b6  Correct bug number
>  add 90e55a9  More prep for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
>  add 837eb2e  Remove unnecessary code.
>  add 7c4361e  Use generics and remove a couple of casts
>  add 79f5924  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
> reported issue
>  add 4c12d98  Follow up to BZ 63781 fix. Restore explicit isPublic
> check.
>  add eecce7a  Additional fix releated to BZ 63781
>  add bc9f590  Ensure correct exception type for defineFunction with
> Java 9+
>  add aaf50d0  Ensure correct exception with ImportHandler and Java 9+
>  add ec7a606  Ensure correct exception with StaticFieldELResolver and
> Java 9+
>  add e8b7ec6  Catch  module export issues at compile time
> if configured to do so
>  add 62a387a  Polish. Formatting.
>  add 2ae5c4b  Polish. Align with 9.0.x. i18n improvements.
>  add cc78a85  Also skip interfaces reported via onStartup()
>  add 39e22eb  Add a module check when processing the scan for server
> endpoints
>  add fd7de63  Update changelog
>  add 37782c6  Fix NPEs when looking for static methods
>  add 434b5dd  Increment version ready for next development cycle
>  add 9d6e09f  Fix typo
>  add 4a9f854  Update URL for code signing service.
>  add 20c39e9  Use consistent format
>  add 7c31429  Expand debugging for async processing
>  add 7839aab  Add debug logging of read/write interest registration
>  add 8db9014  Expand async tests
>  add 570e2c8  Fix instance where pipelined data may be missed after an
> async request
>  add ee83aed  Don't trigger an additional dispatch with async I/O and
> complete
>  add 050fb80  Improve debug logging
>  add c9a87ee  Further align complete()/dispatch() if called during
> async I/O
>  add d91f848  asyncStarted should be false once complete/dispatch in
> onTimeout
>  add 476c7f7  asyncStarted should be false once complete/dispatch 

[Bug 63968] ExpiresFilter: invalid cast

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63968

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Thanks for the report.

Fixed in:
- 8.5.x for 8.5.50 onwards

Only 8.5.x was affected.

-- 
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 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63968 class cast

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt 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 979d8fa  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63968 
class cast
979d8fa is described below

commit 979d8fa00e56f46bb3fe44171c1d472545da2fdf
Author: Mark Thomas 
AuthorDate: Wed Nov 27 16:59:33 2019 +

Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63968 class cast

Fix ClassCastException in the Expires filter which was a regression in
the fix for bug 63909.
---
 java/org/apache/catalina/filters/ExpiresFilter.java | 2 +-
 webapps/docs/changelog.xml  | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/catalina/filters/ExpiresFilter.java 
b/java/org/apache/catalina/filters/ExpiresFilter.java
index 9590f81..8f1dab4 100644
--- a/java/org/apache/catalina/filters/ExpiresFilter.java
+++ b/java/org/apache/catalina/filters/ExpiresFilter.java
@@ -1294,7 +1294,7 @@ public class ExpiresFilter extends FilterBase {
 
 if (innerRequest instanceof 
org.apache.catalina.servlet4preview.http.HttpServletRequest) {
 org.apache.catalina.servlet4preview.http.HttpServletRequest 
servlet4Request =
-
(org.apache.catalina.servlet4preview.http.HttpServletRequest) request;
+
(org.apache.catalina.servlet4preview.http.HttpServletRequest) innerRequest;
 
 if (servlet4Request.getHttpServletMapping().getMappingMatch() 
== MappingMatch.DEFAULT &&
 response.getStatus() == 
HttpServletResponse.SC_NOT_MODIFIED) {
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index efc034a..483f98d 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -57,6 +57,11 @@
 changes introduced in 9.0.28. URLs constructed from URLs obtained from
 the cache could not be used to access resources. (markt)
   
+  
+63968: Fix ClassCastException in the
+Expires filter which was a regression in the fix for
+63909. (markt)
+  
 
   
   


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

Re: Drop SocketWrapperBase.write(Non)BlockingDirect methods

[Mark Thomas]

On 27/11/2019 15:59, Rémy Maucherat wrote:
> On Wed, Nov 27, 2019 at 4:51 PM Mark Thomas  > wrote:
> 
> I've been looking at the 9.0.x changes.
> 
> What is clearer now (I think the differences were always there - just
> harder to see with the more complex code) is that there are some minor
> differences in behaviour when all of the following are true:
> - the source buffer is emptied when it is copied to the socket buffer
> - the socket buffer is full after the source buffer has been copied
> 
> In some cases there will be an immediate write to the network. In other
> cases the network write will wait until the next write to the socket
> buffer or the next explicit flush.
> 
> I think I prefer an immediate write in this scenario. WDYT to updating
> (very carefully) all of the write methods to behave that way?
> 
> 
> Ah personally I did prefer not writing that full buffer (unless the
> source still has data, of course) on purpose since I considered not
> doing IO reduced the likelihood to block on IO (or write 0 for non
> blocking and having to use the poller). That's possible though if you
> like it better.

My preference for writing earlier is only a slight one. I'm more
concerned that different methods take a different approach. Taking a
closer look at that is on my TODO list but it isn't a priority for me at
the moment.

Mark

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

Re: Drop SocketWrapperBase.write(Non)BlockingDirect methods

[Rémy Maucherat]

On Wed, Nov 27, 2019 at 4:51 PM Mark Thomas  wrote:

> I've been looking at the 9.0.x changes.
>
> What is clearer now (I think the differences were always there - just
> harder to see with the more complex code) is that there are some minor
> differences in behaviour when all of the following are true:
> - the source buffer is emptied when it is copied to the socket buffer
> - the socket buffer is full after the source buffer has been copied
>
> In some cases there will be an immediate write to the network. In other
> cases the network write will wait until the next write to the socket
> buffer or the next explicit flush.
>
> I think I prefer an immediate write in this scenario. WDYT to updating
> (very carefully) all of the write methods to behave that way?
>

Ah personally I did prefer not writing that full buffer (unless the source
still has data, of course) on purpose since I considered not doing IO
reduced the likelihood to block on IO (or write 0 for non blocking and
having to use the poller). That's possible though if you like it better.

Rémy

Re: Drop SocketWrapperBase.write(Non)BlockingDirect methods

[Mark Thomas]

On 27/11/2019 12:47, Rémy Maucherat wrote:
> On Tue, Nov 26, 2019 at 2:36 PM Rémy Maucherat  > wrote:
> 
> It looked ok and removed a big chunk of code so I went ahead with it.
> 
> 
> Status update:
>  
> 
> - This one, also the easiest one: drop
> SocketWrapperBase.write(Non)BlockingDirect methods
> 
> 
> Done.

I've been looking at the 9.0.x changes.

What is clearer now (I think the differences were always there - just
harder to see with the more complex code) is that there are some minor
differences in behaviour when all of the following are true:
- the source buffer is emptied when it is copied to the socket buffer
- the socket buffer is full after the source buffer has been copied

In some cases there will be an immediate write to the network. In other
cases the network write will wait until the next write to the socket
buffer or the next explicit flush.

I think I prefer an immediate write in this scenario. WDYT to updating
(very carefully) all of the write methods to behave that way?

Cheers,

Mark

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

[Bug 63948] MultipartFile upload big files over HTTP/2 broken

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63948

Mark Thomas  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Mark Thomas  ---
Thanks Andy. I appreciate the help with this.

All the evidence points towards older versions of curl using small data and/or
continuation and/or window update frames which Tomcat detects as abusive and
therefore closes the connection.

The solution is to use a newer client or disable / reduce the overhead
protection if you need to use an older client.

Marking as INVALID since Tomcat is behaving as intended.

-- 
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 63859] AJP cping/cpong mode failing on Tomcat 9.x

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63859

--- Comment #21 from Aurelien Pernoud  ---
Hi Mark,

the error is not showing for 4 days. Is it possible that you or someone
actually fixed something in this patch too from version 9.0.26 ?? Or Should I
just wait a bit more...

-- 
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 63970] New: java.lang.ClassCastException: org.apache.catalina.webresources.CachedResource$CachedResourceURLConnection cannot be cast to java.net.JarURLConnection

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63970

Bug ID: 63970
   Summary: java.lang.ClassCastException:
org.apache.catalina.webresources.CachedResource$Cached
ResourceURLConnection cannot be cast to
java.net.JarURLConnection
   Product: Tomcat 8
   Version: 8.5.49
  Hardware: PC
OS: Mac OS X 10.1
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: dmitry.tresku...@jetbrains.com
  Target Milestone: 

The following code starts throwing a ClassCastException after upgrading to
Tomcat 8.5.49:

URL url = this.getClass().getResource("/preset.propetries");
String scheme = url.getProtocol();
if ("jar".equals(scheme)) {
  JarURLConnection con = (JarURLConnection) url.openConnection();
}


I guess it happens because of this commit
https://github.com/apache/tomcat/commit/03e7bc8487cb706adf1f56586948a7762dd42d14#diff-b718dcafc40f187cc9aaa1518e63033d

-- 
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 63966] Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

Michael Osipov  changed:

   What|Removed |Added

 CC||micha...@apache.org

-- 
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 63966] Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

--- Comment #2 from Michael Osipov  ---
(In reply to Mark Thomas from comment #1)
> I'm curious. What is the use case for this (other than wanting everything to
> be UTF-8 for $reasons)?
> 
> The response is correctly signalled as ISO-8859-1 encoded and is spec
> compliant.
> 
> To put it another way, I'm struggling to identify a scenario where this
> would not work as intended so why spend time making this configurable?

I share this opinion, one could of course turn into US-ASCII, but hat won't
change anything here.

-- 
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 63969] New: Stackoverflow in JSF

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63969

Bug ID: 63969
   Summary: Stackoverflow in JSF
   Product: Tomcat 9
   Version: 9.0.29
  Hardware: PC
Status: NEW
  Severity: regression
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: ekkelenk...@gmail.com
  Target Milestone: -

When upgrading from Tomcat 9.0.27 to 9.0.29 the following stack overflow
occurs:

java.lang.StackOverflowError
at
java.logging/java.util.logging.LogRecord$CallerFinder.get(LogRecord.java:709)
at
java.logging/java.util.logging.LogRecord.inferCaller(LogRecord.java:683)
at
java.logging/java.util.logging.LogRecord.getSourceMethodName(LogRecord.java:383)
at
org.apache.juli.AsyncFileHandler.publish(AsyncFileHandler.java:112)
at java.logging/java.util.logging.Logger.log(Logger.java:979)
at
java.logging/java.util.logging.Logger.doLog(Logger.java:1006)
at java.logging/java.util.logging.Logger.log(Logger.java:1117)
at
com.sun.faces.application.ApplicationImpl.newThing(ApplicationImpl.java:1735)
at
com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1896)
at
com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1166)
at
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:602)
at
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:175)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at
com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at
com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at
com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at
com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:124)
at
com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:116)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at
com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at
com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at
com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at
com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:124)
at
com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:116)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)

-- 
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 63966] Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

--- Comment #1 from Mark Thomas  ---
I'm curious. What is the use case for this (other than wanting everything to be
UTF-8 for $reasons)?

The response is correctly signalled as ISO-8859-1 encoded and is spec
compliant.

To put it another way, I'm struggling to identify a scenario where this would
not work as intended so why spend time making this configurable?

-- 
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 63937] CORS preflight request not possible on authenticated endpoints

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63937

--- Comment #5 from Michael Osipov  ---
(In reply to Mark Thomas from comment #4)
> Corrected attribute name noted.
> 
> From a Valve we should be able to look into the FilterChain so see if our
> CORS valve is present. For other implementations the user would have to set
> it manually. If there are a small number of standard CORS filter
> implementations with ** be able to look for each of them (by fully
> qualified class name) but this starts heading in a direction I'm rather
> uncomfortable with.

Sounds like a good plan. I fully agree with. I would neither peek for
third-party filters, an explicit true on that attribute is fine.

-- 
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 63937] CORS preflight request not possible on authenticated endpoints

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63937

--- Comment #4 from Mark Thomas  ---
Corrected attribute name noted.

>From a Valve we should be able to look into the FilterChain so see if our CORS
valve is present. For other implementations the user would have to set it
manually. If there are a small number of standard CORS filter implementations
with ** be able to look for each of them (by fully qualified class name)
but this starts heading in a direction I'm rather uncomfortable with.

-- 
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 63968] New: ExpiresFilter: invalid cast

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63968

Bug ID: 63968
   Summary: ExpiresFilter: invalid cast
   Product: Tomcat 8
   Version: 8.5.49
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: cp...@timocom.com
  Target Milestone: 

The getExpirationDate() Method of the ExpiresFilter throws a ClassCastException
when the following conditions hold:
1. the request is ServletRequestWrapper
2. an inner request implements the interface
org.apache.catalina.servlet4preview.http.HttpServletRequest

Then the method will throw a ClassCastException in line 1296 of
org.apache.catalina.filters.ExpiresFilter.

Log Message observed:
Our application uses a custom implementation of a ServletRequestWrapper. The
ClassCastException logs that our custom implementation cannot be cast to
org.apache.catalina.servlet4preview.http.HttpServletRequest

Root Cause
==
The root cause is that if-conditon in line 1295 checks that innerRequest is an
instance of servlet4preview.http.HttpServletRequest, yet in line 1296 the
request (rather than the innerRequest) is casted. 

Out Tomcat Settings:

We use Tomcat 8.5.49 with Connector-Protocol
org.apache.coyote.http11.Http11NioProtocol.

-- 
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: Drop SocketWrapperBase.write(Non)BlockingDirect methods

[Rémy Maucherat]

On Tue, Nov 26, 2019 at 2:36 PM Rémy Maucherat  wrote:

> It looked ok and removed a big chunk of code so I went ahead with it.
>

Status update:


> - This one, also the easiest one: drop
> SocketWrapperBase.write(Non)BlockingDirect methods
>

Done.

Updated port list:
- Remove multipoller from the NIO connector.
- Endpoint generics for the connection type (not fully mandatory but
cleaner).

> - Move the processor tracking to the wrapper and the connection map to the
> endpoint; this one can improve performance
> - The pile ups of close refactoring; big cleanup and move close to the
> wrapper, also improves robustness, I would do it last
>
> Rémy

[Bug 63948] MultipartFile upload big files over HTTP/2 broken

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63948

--- Comment #4 from Andy Wilkinson  ---
Rodrigo, you can customise the Http2Protocol by adding the following bean to
your Spring Boot application:

@Bean
public TomcatConnectorCustomizer http2ProtocolCustomizer() {
  return (connector) -> {
for (UpgradeProtocol upgradeProtocol: connector.findUpgradeProtocols()) {
  if (upgradeProtocol instanceof Http2Protocol) {
Http2Protocol http2Protocol = (Http2Protocol)upgradeProtocol;
http2Protocol.setOverheadContinuationThreshold(0);
http2Protocol.setOverheadDataThreshold(0);
http2Protocol.setOverheadWindowUpdateThreshold(0);
  }
}
  };
}

With this bean in place in your sample application, I'm no longer able to
reproduce the problem with curl 7.54.0 on macOS. With the hint from Mark that
the problem may be client-specific, I also tried with curl 7.67.0 and the
problem does not occur, even without the customization of the Http2Protocol.

-- 
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

[GitHub] [tomcat] michael-o opened a new pull request #226: BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) an…

[GitBox]

michael-o opened a new pull request #226: BZ 63681: Introduce 
RealmBase#authenticate(GSSName, GSSCredential) an…
URL: https://github.com/apache/tomcat/pull/226
 
 
   …d friends
   
   As discussed, introduced a `GSSRealm` derived from `Realm`. Tests pass as 
well as my local code.


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

[tomcat] branch BZ-63681/8.5.x updated (6be96eb -> a0e8d49)

[michaelo]

This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a change to branch BZ-63681/8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


 discard 6be96eb  Frist draft
 add ca38cf1  Fix indent
 add 5c1699a  Deprecate org.apache.tomcat.util.compat.TLS and move its 
functionality to its only using lass org.apache.tomcat.util.net.TesterSupport.
 add 831c6e1  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63753 WS 
host header
 add 07f3c37  Fix test failures caused by APR crash during shutdown
 add b7ae3eb  Add release date for 8.5.46
 add 6dae407  Revert "Fix test failures caused by APR crash during shutdown"
 add 99e5ea8  Add Javadoc for the Common Annotation API
 add 8b7ade1  Correct version number
 add da37f36  https://bz.apache.org/bugzilla/show_bug.cgi?id=63759 
Uninstaller & UAC
 add 4e984dc  Polish. Align spacing, remove svn (and cvs!) references
 add c24a6ae  Align Java version references
 add c8ddc6f  Update link to point to Java 7 javadoc
 add ce4f6b7  Parameterise minimum Java version
 add c9f3362  Fix xml source file that wasn't using expected version 
replacement
 add 39bcbd0  Fix xml source file that wasn't using expected version 
replacement
 add 993e80e  BZ63765: Try to unwrap first after handshake
 add 3aba970  Fix test failures with APR/native.
 add 5dda8bf  Fix incorrect default value of maxThreads in cluster receiver 
docs.
 add 8c2f067  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63766
 add d817d1e  Align with 9.0.x. Spacing, Javadoc
 add 2a26382  Add throwOnFailure to LifecycleBase.
 add 8fc21ef  Fix indent
 add 0378b4b  Align Javadoc with 9.0.x
 add 30f7e93  Align with 9.0.x. Mostly Javadoc with a little refactoring.
 add 1b0c02c  Align with 9.0.x. Spacing.
 add d9f4dd4  Align with 9.0.x - spacing
 add 71deb4b  Align with 9.0.x - spacing, i18n
 add f3c4438  Align with 9.0.x- spacing, l10n
 add c9fda66  Align with 9.0.x
 add 02bbd57  Align with 9.0.x spacing
 add 845d972  Align with 9.0.x - spacing
 add 8dbabe3  Fix alignment of start-up messages
 add 74cd321  Fix open transaction after validation
 add 98943df  Add logging
 add a7e6a5d  Add logging
 add 0bcf094  Try and detect bugs like BZ 63778
 add 7c15360  Try and detect bugs like BZ 63778
 add fa8de32  Fix typos
 add cc85b6c  Fixes having an issue number are sorted by their number, 
ascending.
 add 7637860  Remove unnecessary @SuppressWarnings
 add 260133b  Remove unused code
 add b5d2660  Prep fix for 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
 add c110bf8  Update to Commons Daemon 1.2.2
 add 1de02b6  Correct bug number
 add 90e55a9  More prep for 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63781
 add 837eb2e  Remove unnecessary code.
 add 7c4361e  Use generics and remove a couple of casts
 add 79f5924  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63781 
reported issue
 add 4c12d98  Follow up to BZ 63781 fix. Restore explicit isPublic check.
 add eecce7a  Additional fix releated to BZ 63781
 add bc9f590  Ensure correct exception type for defineFunction with Java 9+
 add aaf50d0  Ensure correct exception with ImportHandler and Java 9+
 add ec7a606  Ensure correct exception with StaticFieldELResolver and Java 
9+
 add e8b7ec6  Catch  module export issues at compile time if 
configured to do so
 add 62a387a  Polish. Formatting.
 add 2ae5c4b  Polish. Align with 9.0.x. i18n improvements.
 add cc78a85  Also skip interfaces reported via onStartup()
 add 39e22eb  Add a module check when processing the scan for server 
endpoints
 add fd7de63  Update changelog
 add 37782c6  Fix NPEs when looking for static methods
 add 434b5dd  Increment version ready for next development cycle
 add 9d6e09f  Fix typo
 add 4a9f854  Update URL for code signing service.
 add 20c39e9  Use consistent format
 add 7c31429  Expand debugging for async processing
 add 7839aab  Add debug logging of read/write interest registration
 add 8db9014  Expand async tests
 add 570e2c8  Fix instance where pipelined data may be missed after an 
async request
 add ee83aed  Don't trigger an additional dispatch with async I/O and 
complete
 add 050fb80  Improve debug logging
 add c9a87ee  Further align complete()/dispatch() if called during async I/O
 add d91f848  asyncStarted should be false once complete/dispatch in 
onTimeout
 add 476c7f7  asyncStarted should be false once complete/dispatch in onError
 add a7da104  63765: Properly mark container as FAILED when a JVM error 
occurs on stop # Conflicts: #   webapps/docs/changelog.xml
 add b57c622  Add test case for bug 63816
 add bf24a92  Add debug log messages for the triggering of async listener 
events
 add 0495f66  Fix 

[tomcat] 01/01: BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) and friends

[michaelo]

This is an automated email from the ASF dual-hosted git repository.

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

commit a0e8d49197a98b92e28cf30f186f1708658d3159
Author: Michael Osipov 
AuthorDate: Wed Aug 21 23:23:19 2019 +0200

BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) and 
friends
---
 java/org/apache/catalina/GSSRealm.java| 45 
 java/org/apache/catalina/realm/CombinedRealm.java | 43 
 java/org/apache/catalina/realm/LockOutRealm.java  | 13 +
 java/org/apache/catalina/realm/RealmBase.java | 62 ++-
 webapps/docs/changelog.xml|  4 ++
 5 files changed, 155 insertions(+), 12 deletions(-)

diff --git a/java/org/apache/catalina/GSSRealm.java 
b/java/org/apache/catalina/GSSRealm.java
new file mode 100644
index 000..9638c2b
--- /dev/null
+++ b/java/org/apache/catalina/GSSRealm.java
@@ -0,0 +1,45 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina;
+
+import java.security.Principal;
+
+import org.ietf.jgss.GSSCredential;
+import org.ietf.jgss.GSSName;
+
+/**
+ * A GSSRealm is a specialized realm for GSS-based usernames.
+ *
+ * @deprecated To be removed in Tomcat 9.0 and integrated into {@link Realm}.
+ */
+@Deprecated
+public interface GSSRealm extends Realm {
+
+
+// - Public Methods
+
+/**
+ * Try to authenticate using a {@link GSSName}
+ *
+ * @param gssName The {@link GSSName} of the principal to look up
+ * @param gssCredential The {@link GSSCredential} of the principal, may be
+ *  {@code null}
+ * @return the associated principal, or {@code null} if there is none
+ */
+public Principal authenticate(GSSName gssName, GSSCredential 
gssCredential);
+
+}
diff --git a/java/org/apache/catalina/realm/CombinedRealm.java 
b/java/org/apache/catalina/realm/CombinedRealm.java
index 59511fa..cd64d99 100644
--- a/java/org/apache/catalina/realm/CombinedRealm.java
+++ b/java/org/apache/catalina/realm/CombinedRealm.java
@@ -26,12 +26,14 @@ import java.util.List;
 import javax.management.ObjectName;
 
 import org.apache.catalina.Container;
+import org.apache.catalina.GSSRealm;
 import org.apache.catalina.Lifecycle;
 import org.apache.catalina.LifecycleException;
 import org.apache.catalina.Realm;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.ietf.jgss.GSSContext;
+import org.ietf.jgss.GSSCredential;
 import org.ietf.jgss.GSSException;
 import org.ietf.jgss.GSSName;
 
@@ -393,6 +395,47 @@ public class CombinedRealm extends RealmBase {
 return null;
 }
 
+/**
+ * {@inheritDoc}
+ */
+@Override
+public Principal authenticate(GSSName gssName, GSSCredential 
gssCredential) {
+Principal authenticatedUser = null;
+String username = gssName.toString();
+
+for (Realm realm : realms) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authStart",
+username, realm.getClass().getName()));
+}
+
+if (!(realm instanceof GSSRealm)) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authFail",
+username, realm.getClass().getName()));
+}
+
+continue;
+}
+
+authenticatedUser = ((GSSRealm) realm).authenticate(gssName, 
gssCredential);
+
+if (authenticatedUser == null) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authFail",
+username, realm.getClass().getName()));
+}
+} else {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authSuccess",
+username, realm.getClass().getName()));
+}
+break;
+}
+}
+return authenticatedUser;
+}
+
 @Override
 

[tomcat] branch 8.5.x updated: Simplify regular endpoint writes by removing write(Non)BlockingDirect

[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 7d2365d  Simplify regular endpoint writes by removing 
write(Non)BlockingDirect
7d2365d is described below

commit 7d2365d4e302717140946e019b63f05598b4a080
Author: remm 
AuthorDate: Wed Nov 27 10:30:15 2019 +0100

Simplify regular endpoint writes by removing write(Non)BlockingDirect

Port patch from trunk/9.0.
---
 java/org/apache/tomcat/util/net/AprEndpoint.java   |  51 ---
 .../apache/tomcat/util/net/SocketWrapperBase.java  | 100 -
 webapps/docs/changelog.xml |   5 ++
 3 files changed, 22 insertions(+), 134 deletions(-)

diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index 927dd01..64f0257 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -2330,57 +2330,6 @@ public class AprEndpoint extends AbstractEndpoint 
implements SNICallBack {
 
 
 @Override
-protected void writeBlockingDirect(ByteBuffer from) throws IOException 
{
-if (from.isDirect()) {
-super.writeBlockingDirect(from);
-} else {
-// The socket write buffer capacity is socket.appWriteBufSize
-ByteBuffer writeBuffer = socketBufferHandler.getWriteBuffer();
-int limit = writeBuffer.capacity();
-while (from.remaining() >= limit) {
-socketBufferHandler.configureWriteBufferForWrite();
-transfer(from, writeBuffer);
-doWrite(true);
-}
-
-if (from.remaining() > 0) {
-socketBufferHandler.configureWriteBufferForWrite();
-transfer(from, writeBuffer);
-}
-}
-}
-
-
-@Override
-protected void writeNonBlockingDirect(ByteBuffer from) throws 
IOException {
-if (from.isDirect()) {
-super.writeNonBlockingDirect(from);
-} else {
-// The socket write buffer capacity is socket.appWriteBufSize
-ByteBuffer writeBuffer = socketBufferHandler.getWriteBuffer();
-int limit = writeBuffer.capacity();
-while (from.remaining() >= limit) {
-socketBufferHandler.configureWriteBufferForWrite();
-transfer(from, writeBuffer);
-int newPosition = writeBuffer.position() + limit;
-doWrite(false);
-if (writeBuffer.position() != newPosition) {
-// Didn't write the whole amount of data in the last
-// non-blocking write.
-// Exit the loop.
-return;
-}
-}
-
-if (from.remaining() > 0) {
-socketBufferHandler.configureWriteBufferForWrite();
-transfer(from, writeBuffer);
-}
-}
-}
-
-
-@Override
 protected void doWrite(boolean block, ByteBuffer from) throws 
IOException {
 if (closed) {
 throw new IOException(sm.getString("socket.apr.closed", 
getSocket()));
diff --git a/java/org/apache/tomcat/util/net/SocketWrapperBase.java 
b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
index dd5e741..545d333 100644
--- a/java/org/apache/tomcat/util/net/SocketWrapperBase.java
+++ b/java/org/apache/tomcat/util/net/SocketWrapperBase.java
@@ -403,8 +403,6 @@ public abstract class SocketWrapperBase {
  * - To enable a marginally more efficient implemented for blocking
  *   writes which do not require the additional checks related to the
  *   use of the non-blocking write buffer
- *   TODO: Explore re-factoring options to remove the split into
- * separate methods
  */
 if (block) {
 writeBlocking(buf, off, len);
@@ -452,8 +450,6 @@ public abstract class SocketWrapperBase {
  * - To enable a marginally more efficient implemented for blocking
  *   writes which do not require the additional checks related to the
  *   use of the non-blocking write buffer
- *   TODO: Explore re-factoring options to remove the split into
- * separate methods
  */
 if (block) {
 writeBlocking(from);
@@ -481,7 +477,7 @@ public abstract class SocketWrapperBase {
 protected void writeBlocking(byte[] buf, int off, int len) throws 
IOException {
 socketBufferHandler.configureWriteBufferForWrite();
 int thisTime = transfer(buf, off, len, 

[Bug 63966] Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

Remy Maucherat  changed:

   What|Removed |Added

   Severity|normal  |enhancement

-- 
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

[GitHub] [tomcat] michael-o commented on issue #225: BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) an…

[GitBox]

michael-o commented on issue #225: BZ 63681: Introduce 
RealmBase#authenticate(GSSName, GSSCredential) an…
URL: https://github.com/apache/tomcat/pull/225#issuecomment-559002699
 
 
   Default method added, 8.5.x in preparation.


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 63966] New: Charset of TLS message is hardcoded to ISO-8859-1.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63966

Bug ID: 63966
   Summary: Charset of TLS message is hardcoded to ISO-8859-1.
   Product: Tomcat 8
   Version: 8.5.32
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: madhavpulip...@gmail.com
  Target Milestone: 

Hi,

Tomcat shows error as "This combination of host and port requires TLS." when
user is trying to access a URL using http where https is required. In our
application all the requests and responses use UTF-8 only. Since this message
is hardcoded in org.apache.tomcat.util.net.TLSClientHelloExtractor.java with
ISO-8859-1, we could not instruct tomcat to show this message using UTF-8. Can
you please fix this and let us know configuration to pass charset that tomcat
can use for this message.


thanks and regards,
Madhav Pulipaka

-- 
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 BZ-63681/9.0.x updated (9062436 -> d987d94)

[michaelo]

This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a change to branch BZ-63681/9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


omit 9062436  BZ 63681: Introduce RealmBase#authenticate(GSSName, 
GSSCredential) and friends
 add 50feb56  Add release date for 9.0.29
 add f5f2b62  BZ63949: Restore write loop which was present in the selector 
code
 add 76ab416  Fix javadoc @see reference.
 add b2e3596  .gitignore - Add .ant-targets-build.xml file to gitignore.
 add e160e53  Fix potential test failure / hang if timing isn't as expected
 add a42b94a  may sure the arbitrarily assigned user ID of openshift can 
deploy a war file.
 add 33eccc7  Simplify regular endpoint writes by removing 
write(Non)BlockingDirect
 add fba885d  Revert the fix for 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63815
 add 2347e32  Reduce differences with 8.5
 add c36e285  Update to OWB 2.0.13
 add e1919b4  Partial fix for 
https://bz.apache.org/bugzilla/show_bug.cgi?id=63815
 add d760a78  Update changelog
 add cd47ca9  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 
Cached URLs
 new d987d94  BZ 63681: Introduce RealmBase#authenticate(GSSName, 
GSSCredential) and friends

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (9062436)
\
 N -- N -- N   refs/heads/BZ-63681/9.0.x (d987d94)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 .gitignore |   1 +
 bin/catalina.sh|   8 +-
 bin/daemon.sh  |  66 ++---
 bin/tool-wrapper.sh|   8 +-
 java/org/apache/catalina/Realm.java|   4 +-
 .../apache/catalina/servlets/WebdavServlet.java|   2 +-
 .../catalina/webresources/CachedResource.java  |  12 ++-
 java/org/apache/tomcat/util/net/AprEndpoint.java   |  51 --
 java/org/apache/tomcat/util/net/NioEndpoint.java   |  10 +-
 .../apache/tomcat/util/net/SocketWrapperBase.java  | 104 -
 modules/owb/pom.xml|   2 +-
 res/tomcat-maven/Dockerfile|   1 +
 .../core/TestAsyncContextStateChanges.java |   7 ++
 ...lerIntegration.java => TestCachedResource.java} |  30 +++---
 webapps/docs/changelog.xml |  29 +-
 15 files changed, 138 insertions(+), 197 deletions(-)
 copy test/org/apache/catalina/webresources/{war/TestHandlerIntegration.java => 
TestCachedResource.java} (67%)


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

[tomcat] 01/01: BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) and friends

[michaelo]

This is an automated email from the ASF dual-hosted git repository.

michaelo pushed a commit to branch BZ-63681/9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d987d942aecf557133df9399592ebfc0b77f9968
Author: Michael Osipov 
AuthorDate: Wed Aug 21 23:23:19 2019 +0200

BZ 63681: Introduce RealmBase#authenticate(GSSName, GSSCredential) and 
friends
---
 java/org/apache/catalina/Realm.java   | 15 ++
 java/org/apache/catalina/realm/CombinedRealm.java | 33 +
 java/org/apache/catalina/realm/LockOutRealm.java  | 13 +
 java/org/apache/catalina/realm/RealmBase.java | 58 +++
 webapps/docs/changelog.xml|  4 ++
 5 files changed, 113 insertions(+), 10 deletions(-)

diff --git a/java/org/apache/catalina/Realm.java 
b/java/org/apache/catalina/Realm.java
index 7785ec2..1acf6e3 100644
--- a/java/org/apache/catalina/Realm.java
+++ b/java/org/apache/catalina/Realm.java
@@ -25,6 +25,8 @@ import org.apache.catalina.connector.Request;
 import org.apache.catalina.connector.Response;
 import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
 import org.ietf.jgss.GSSContext;
+import org.ietf.jgss.GSSCredential;
+import org.ietf.jgss.GSSName;
 
 /**
  * A Realm is a read-only facade for an underlying security realm
@@ -117,6 +119,19 @@ public interface Realm extends Contained {
 
 
 /**
+ * Try to authenticate using a {@link GSSName}
+ *
+ * @param gssName The {@link GSSName} of the principal to look up
+ * @param gssCredential The {@link GSSCredential} of the principal, may be
+ *  {@code null}
+ * @return the associated principal, or {@code null} if there is none
+ */
+public default Principal authenticate(GSSName gssName, GSSCredential 
gssCredential) {
+return null;
+}
+
+
+/**
  * Try to authenticate using {@link X509Certificate}s
  *
  * @param certs Array of client certificates, with the first one in
diff --git a/java/org/apache/catalina/realm/CombinedRealm.java 
b/java/org/apache/catalina/realm/CombinedRealm.java
index 6a73b0f..6bbc238 100644
--- a/java/org/apache/catalina/realm/CombinedRealm.java
+++ b/java/org/apache/catalina/realm/CombinedRealm.java
@@ -32,6 +32,7 @@ import org.apache.catalina.Realm;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.ietf.jgss.GSSContext;
+import org.ietf.jgss.GSSCredential;
 import org.ietf.jgss.GSSException;
 import org.ietf.jgss.GSSName;
 
@@ -386,6 +387,38 @@ public class CombinedRealm extends RealmBase {
 return null;
 }
 
+/**
+ * {@inheritDoc}
+ */
+@Override
+public Principal authenticate(GSSName gssName, GSSCredential 
gssCredential) {
+Principal authenticatedUser = null;
+String username = gssName.toString();
+
+for (Realm realm : realms) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authStart",
+username, realm.getClass().getName()));
+}
+
+authenticatedUser = realm.authenticate(gssName, gssCredential);
+
+if (authenticatedUser == null) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authFail",
+username, realm.getClass().getName()));
+}
+} else {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("combinedRealm.authSuccess",
+username, realm.getClass().getName()));
+}
+break;
+}
+}
+return authenticatedUser;
+}
+
 @Override
 protected String getPassword(String username) {
 // This method should never be called
diff --git a/java/org/apache/catalina/realm/LockOutRealm.java 
b/java/org/apache/catalina/realm/LockOutRealm.java
index aa4820a..28ce315 100644
--- a/java/org/apache/catalina/realm/LockOutRealm.java
+++ b/java/org/apache/catalina/realm/LockOutRealm.java
@@ -27,6 +27,7 @@ import org.apache.catalina.LifecycleException;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.ietf.jgss.GSSContext;
+import org.ietf.jgss.GSSCredential;
 import org.ietf.jgss.GSSException;
 import org.ietf.jgss.GSSName;
 
@@ -200,6 +201,18 @@ public class LockOutRealm extends CombinedRealm {
 return null;
 }
 
+/**
+ * {@inheritDoc}
+ */
+@Override
+public Principal authenticate(GSSName gssName, GSSCredential 
gssCredential) {
+String username = gssName.toString();
+
+Principal authenticatedUser = super.authenticate(gssName, 
gssCredential);
+
+return filterLockedAccounts(username, authenticatedUser);
+}
+
 
 /*
  * Filters authenticated principals to ensure that null is
diff --git a/java/org/apache/catalina/realm/RealmBase.java