[Bug 65448] Download of file via Servlet OutputStream blocks when using SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=65448 --- Comment #4 from Roman --- One other thing: how would the code be influenced by the connection timeout of the server? It's not that the client opens a new connection or something... it's just that the server pauses sending the response. I would not know how to even write the code on purpose so that it is related to the connection timeout. -- 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 65448] Download of file via Servlet OutputStream blocks when using SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=65448 --- Comment #3 from Roman --- Yes, absolutely. We even pulled the code out to a separate app to check it individually. My main point is that it works when using HTTP. And it is really a small code and I would consider it to be ok. -- 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 65448] Download of file via Servlet OutputStream blocks when using SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=65448 --- Comment #2 from Michael Osipov --- If the DefaultServlet is working via HTTPS then the error is in your code. Did you check that? -- 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 65448] Download of file via Servlet OutputStream blocks when using SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=65448 Roman changed: What|Removed |Added OS||All --- Comment #1 from Roman --- Important thing that I forgot: when downloading files directly via Tomcat, it also works all the time. Only the combination of the Servlet with HTTPS causes issues. We have no problem when using 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 65448] New: Download of file via Servlet OutputStream blocks when using SSL
https://bz.apache.org/bugzilla/show_bug.cgi?id=65448
Bug ID: 65448
Summary: Download of file via Servlet OutputStream blocks when
using SSL
Product: Tomcat 9
Version: 9.0.50
Hardware: PC
Status: NEW
Severity: major
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ro...@auxilii.com
Target Milestone: -
Created attachment 37950
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37950=edit
A ZIP file containing curl outputs, threaddumps and system information
We have a very simple Servlet implementation that lets clients download a file.
Here's the code:
try (InputStream in = new BufferedInputStream(new
FileInputStream(resourceFile), IOTools.SIZE_64K)) {
IOTools.pump(in, response.getOutputStream());
}
The pump method copies the bytes from the InputStream to the OutputStream (in
blocks of 64K) and flushes the OutputStream after that.
The problem:
When downloading a file with cURL command:
curl -v --insecure
"https://btdevapp01:8443/tribefire-services/res/adx/fonts/exactly130703.txt;
--output test.txt
it will block halfway through the response and will wait 1 min until the
download resumes and finishes successfully.
Here are some observations:
* When the downloaded file is below the size of 130.703 Bytes, the download
works all the time. Only when the file is greater or equal to 130.073 Bytes,
the download might fail.
* The 1 min waiting period is related to the configured "connectionTimeout" in
the server.xml. When we increase that config to - say - 120.000, we have to
wait 2 minutes until the download finishes.
* This problem only occurs when using HTTPS. When using the equivalent HTTP
address, it works all the time for all file sizes.
* This is not just a problem with cURL. We were able to reproduce problems with
Chrome 91 and Firefox 90.
* With the help of JMX, we can read out that the Maximum Request Time of the
HTTPS Connectors is 3487 ms. Hence, it does not register that the user has to
wait over a minute to get the full result.
We were not able to reproduce the problem on our local environments, but this
might also be because we're using mostly Macs and the target platform where we
encounter the problem is Windows Server 2019.
I am attaching the following:
* cURL output of downloading the same file twice, one time it is ok
(curl-working.txt) and one time when it fails (curl-failing.txt)
* Threaddumps of the server, one while it is idle (threaddump-idle.txt), one
when it is blocking (threaddump-blocking.txt) (where I cannot find anything
suspicious).
* Information about the server (Tomcat and Host) in server-info.txt
* A video showing how downloading the same file works 7 times, then fails, and
after that works again (edit: this exceeds the limit of the ticketing
system but can be provided on request)
I understand that this is very little to work with but this is all the
information that we could compile.
--
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 65358] Possible EL Bug — Method Matching with Varargs
https://bz.apache.org/bugzilla/show_bug.cgi?id=65358 --- Comment #6 from Mark Thomas --- Yes, that looks like a bug to me. The JLS states (in rather more precise language) that a method match that doesn't use varargs beats one that does. I'll work on a fix. -- 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 65358] Possible EL Bug — Method Matching with Varargs
https://bz.apache.org/bugzilla/show_bug.cgi?id=65358
Volodymyr Siedlecki changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #5 from Volodymyr Siedlecki ---
I was looking at this again (on 9.0.50).
I think there's still a bug here? Using the code below:
Bean bean = new Bean();
// JVM
bean.bark(bean.getDog()); // -> bark(Animal animal)
// EL
${ bean.bark(bean.dog) } // - > bark(Dog dog, String... text)
___
public interface Animal {
}
public class Dog implements Animal {
}
public class Bean {
public String bark(Animal animal){
return "bark(Animal animal)";
}
public String bark(Dog dog, String... text){
return "bark(Dog dog, String... text)";
}
public Animal getDog(){
System.out.println("Returning Dog of type Animal");
return new Dog();
}
}
--
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: https://bz.apache.org/bugzilla/show_bug.cgi?id=55707 in tomcat
On 09/07/2021 18:40, Rainer Jung wrote: Hi Jean-Frederic, how do you make sure, that your tests actually land in the correct SSLHost? You are using the same server certificate, so a check on the client side might not be easy. I would find a test more convincing, if the three TLS hosts would use three different certificates and you could check on the TLS client, that it actually gets the right server certificate. Yes I have retested with 3 different certificates localhost gets the localhost certificate and the TLSv1.1 protocol server1 gets the server1 certificate but the TLSv1.1 protocol server2 gets the server2 certificate but the TLSv1.1 protocol... Use nio/nio2 the protocol is the expected one. Best regards, Rainer Am 09.07.2021 um 15:33 schrieb jean-frederic clere: On 09/07/2021 15:15, Christopher Schultz wrote: Jean-Ferderic, On 7/9/21 07:55, jean-frederic clere wrote: On 09/07/2021 12:38, Mark Thomas wrote: On 09/07/2021 11:08, jean-frederic clere wrote: Hi, I think we need the same fix in tomcat or I missed something? If we need it I will work on it next week ;-) To clarify, you mean checking Tomcat can (and implementing if it can't) the ability to configure supported SSL protocols per virtual host. Yes. We should have most of this in SSLHostConfig but I don't recall ever testing this behaviour specifically. Just as a reminder, both elements and .../> are likely to be required as the are configured separately. Quick test and code review seems to show it is not working (I tested the apr connector and 9.0.x). Can you post a sample config? I assume you mean: 1. Define two , configure for TLS a. One attempting to use e.g. only TLSv1 b. One attempting to use e.g. only TLSv1.2 2. Run a protocol-checker against both hosts Result is that host (a) supports not-only TLSv1 and/or host (b) supports not-only TLSv1.2? Yes that is what I am testing, actually Nio and Nio2 are working Apr isn't... The configuration is something like: +++ +++ and I have the 3 corresponding -- Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65443] Allow subclassing CorsFilter
https://bz.apache.org/bugzilla/show_bug.cgi?id=65443 --- Comment #6 from ekkelenk...@gmail.com --- Thanks for the feedback. The requirement is indeed to be able to configure the allowed origins at runtime. Should I provide a pull request for this enhancement or is this kind of refactoring done by the core developers? -- 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 65443] Allow subclassing CorsFilter
https://bz.apache.org/bugzilla/show_bug.cgi?id=65443 --- Comment #5 from Mark Thomas --- The initial implementation was clearly on the basis that the state was set during init() and then never changed but if you have a requirement to change it then I don't see a good reason not to refactor the code and provide setters. I'll note that other built-in filters have getters and setters. -- 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] markt-asf commented on pull request #433: Fix typo
markt-asf commented on pull request #433: URL: https://github.com/apache/tomcat/pull/433#issuecomment-878847653 Thanks for the PR. Please note that trailing whitespace should be removed from all lines. If you run checkstyle using the provided configuration, it should catch issues like that. -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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 typo (#433)
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 b363fba Fix typo (#433)
b363fba is described below
commit b363fbad6a4539eaaf44b6e62d6ab1646d31851c
Author: Shi.Kun <34267068+pachul...@users.noreply.github.com>
AuthorDate: Tue Jul 13 15:21:42 2021 +0800
Fix typo (#433)
* Fix typo
add missing words
---
java/javax/servlet/ServletSecurityElement.java | 2 ++
1 file changed, 2 insertions(+)
diff --git a/java/javax/servlet/ServletSecurityElement.java
b/java/javax/servlet/ServletSecurityElement.java
index 875d103..d7e0116 100644
--- a/java/javax/servlet/ServletSecurityElement.java
+++ b/java/javax/servlet/ServletSecurityElement.java
@@ -71,6 +71,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* @param httpConstraintElement Default constraint
* @param httpMethodConstraints Method constraints
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(HttpConstraintElement httpConstraintElement,
Collection httpMethodConstraints) {
@@ -84,6 +85,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* Create from an annotation.
* @param annotation Annotation to use as the basis for the new instance
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(ServletSecurity annotation) {
this(new HttpConstraintElement(annotation.value().value(),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Fix typo (#433)
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 0dffb1d Fix typo (#433)
0dffb1d is described below
commit 0dffb1d93d6df01dfa62606ea536b0ef6aaf459c
Author: Shi.Kun <34267068+pachul...@users.noreply.github.com>
AuthorDate: Tue Jul 13 15:21:42 2021 +0800
Fix typo (#433)
* Fix typo
add missing words
---
java/javax/servlet/ServletSecurityElement.java | 2 ++
1 file changed, 2 insertions(+)
diff --git a/java/javax/servlet/ServletSecurityElement.java
b/java/javax/servlet/ServletSecurityElement.java
index 875d103..d7e0116 100644
--- a/java/javax/servlet/ServletSecurityElement.java
+++ b/java/javax/servlet/ServletSecurityElement.java
@@ -71,6 +71,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* @param httpConstraintElement Default constraint
* @param httpMethodConstraints Method constraints
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(HttpConstraintElement httpConstraintElement,
Collection httpMethodConstraints) {
@@ -84,6 +85,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* Create from an annotation.
* @param annotation Annotation to use as the basis for the new instance
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(ServletSecurity annotation) {
this(new HttpConstraintElement(annotation.value().value(),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.0.x updated: Fix typo (#433)
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.0.x by this push:
new 054c3d1 Fix typo (#433)
054c3d1 is described below
commit 054c3d10940db59d3a96b8bc7ecc0933811c6b62
Author: Shi.Kun <34267068+pachul...@users.noreply.github.com>
AuthorDate: Tue Jul 13 15:21:42 2021 +0800
Fix typo (#433)
* Fix typo
add missing words
---
java/jakarta/servlet/ServletSecurityElement.java | 2 ++
1 file changed, 2 insertions(+)
diff --git a/java/jakarta/servlet/ServletSecurityElement.java
b/java/jakarta/servlet/ServletSecurityElement.java
index 4f8d469..25a98d0c 100644
--- a/java/jakarta/servlet/ServletSecurityElement.java
+++ b/java/jakarta/servlet/ServletSecurityElement.java
@@ -71,6 +71,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* @param httpConstraintElement Default constraint
* @param httpMethodConstraints Method constraints
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(HttpConstraintElement httpConstraintElement,
Collection httpMethodConstraints) {
@@ -84,6 +85,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* Create from an annotation.
* @param annotation Annotation to use as the basis for the new instance
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(ServletSecurity annotation) {
this(new HttpConstraintElement(annotation.value().value(),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Remove trailing space
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 85ff05f Remove trailing space
85ff05f is described below
commit 85ff05f396ffdb19a2df69123f51f8c784e95ee0
Author: Mark Thomas
AuthorDate: Tue Jul 13 08:24:17 2021 +0100
Remove trailing space
---
java/jakarta/servlet/ServletSecurityElement.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/jakarta/servlet/ServletSecurityElement.java
b/java/jakarta/servlet/ServletSecurityElement.java
index 549f199..25a98d0c 100644
--- a/java/jakarta/servlet/ServletSecurityElement.java
+++ b/java/jakarta/servlet/ServletSecurityElement.java
@@ -84,7 +84,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
/**
* Create from an annotation.
* @param annotation Annotation to use as the basis for the new instance
- * @throws IllegalArgumentException if a method name is specified more
than
+ * @throws IllegalArgumentException if a method name is specified more than
* once
*/
public ServletSecurityElement(ServletSecurity annotation) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat] markt-asf merged pull request #433: Fix typo
markt-asf merged pull request #433: URL: https://github.com/apache/tomcat/pull/433 -- 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. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Fix typo (#433)
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new b5d84e4 Fix typo (#433)
b5d84e4 is described below
commit b5d84e4299668795fac658aa64ea151cf653684c
Author: Shi.Kun <34267068+pachul...@users.noreply.github.com>
AuthorDate: Tue Jul 13 15:21:42 2021 +0800
Fix typo (#433)
* Fix typo
add missing words
---
java/jakarta/servlet/ServletSecurityElement.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/java/jakarta/servlet/ServletSecurityElement.java
b/java/jakarta/servlet/ServletSecurityElement.java
index 4f8d469..549f199 100644
--- a/java/jakarta/servlet/ServletSecurityElement.java
+++ b/java/jakarta/servlet/ServletSecurityElement.java
@@ -71,6 +71,7 @@ public class ServletSecurityElement extends
HttpConstraintElement {
* @param httpConstraintElement Default constraint
* @param httpMethodConstraints Method constraints
* @throws IllegalArgumentException if a method name is specified more than
+ * once
*/
public ServletSecurityElement(HttpConstraintElement httpConstraintElement,
Collection httpMethodConstraints) {
@@ -83,7 +84,8 @@ public class ServletSecurityElement extends
HttpConstraintElement {
/**
* Create from an annotation.
* @param annotation Annotation to use as the basis for the new instance
- * @throws IllegalArgumentException if a method name is specified more than
+ * @throws IllegalArgumentException if a method name is specified more
than
+ * once
*/
public ServletSecurityElement(ServletSecurity annotation) {
this(new HttpConstraintElement(annotation.value().value(),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
