buildbot success in on tomcat-7-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1738

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] 917b3b402a512bb9a432a972499fd49b5f984cb3
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




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

buildbot success in on tomcat-9-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-9-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-9-trunk/builds/330

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' 
triggered this build
Build Source Stamp: [branch 9.0.x] 47157c416c73dff5d461a81830b2836c47605e1e
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




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

[tomcat] branch 7.0.x updated: Refactor sis.available() for more accurate return value

[markt]

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 917b3b4  Refactor sis.available() for more accurate return value
917b3b4 is described below

commit 917b3b402a512bb9a432a972499fd49b5f984cb3
Author: Mark Thomas 
AuthorDate: Mon Jul 6 19:33:00 2020 +0100

Refactor sis.available() for more accurate return value
---
 java/org/apache/coyote/InputBuffer.java|  9 +
 java/org/apache/coyote/ajp/AbstractAjpProcessor.java   | 14 +-
 java/org/apache/coyote/http11/InputFilter.java | 11 +--
 java/org/apache/coyote/http11/InternalAprInputBuffer.java  | 14 ++
 java/org/apache/coyote/http11/InternalInputBuffer.java | 14 ++
 java/org/apache/coyote/http11/InternalNioInputBuffer.java  | 14 ++
 .../apache/coyote/http11/filters/BufferedInputFilter.java  |  9 +++--
 .../apache/coyote/http11/filters/ChunkedInputFilter.java   |  8 +++-
 .../apache/coyote/http11/filters/IdentityInputFilter.java  |  3 ++-
 webapps/docs/changelog.xml |  9 +
 10 files changed, 74 insertions(+), 31 deletions(-)

diff --git a/java/org/apache/coyote/InputBuffer.java 
b/java/org/apache/coyote/InputBuffer.java
index a38cc5c..cbb502f 100644
--- a/java/org/apache/coyote/InputBuffer.java
+++ b/java/org/apache/coyote/InputBuffer.java
@@ -45,4 +45,13 @@ public interface InputBuffer {
 throws IOException;
 
 
+/**
+ * Obtain an estimate of the number of bytes that can be read without
+ * blocking. Typically, this will be the number of available bytes known to
+ * be buffered.
+ *
+ * @return The number of bytes that can be read without blocking
+ */
+public int available();
+
 }
diff --git a/java/org/apache/coyote/ajp/AbstractAjpProcessor.java 
b/java/org/apache/coyote/ajp/AbstractAjpProcessor.java
index 7016e41..93d01c3 100644
--- a/java/org/apache/coyote/ajp/AbstractAjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AbstractAjpProcessor.java
@@ -1218,20 +1218,17 @@ public abstract class AbstractAjpProcessor extends 
AbstractProcessor {
 
 // - InputStreamInputBuffer Inner Class
 
-
 /**
  * This class is an input buffer which will read its data from an input
  * stream.
  */
 protected class SocketInputBuffer implements InputBuffer {
 
-
 /**
  * Read bytes into the specified chunk.
  */
 @Override
-public int doRead(ByteChunk chunk, Request req)
-throws IOException {
+public int doRead(ByteChunk chunk, Request req) throws IOException {
 
 if (endOfStream) {
 return -1;
@@ -1250,9 +1247,16 @@ public abstract class AbstractAjpProcessor extends 
AbstractProcessor {
 chunk.setBytes(bc.getBuffer(), bc.getStart(), bc.getLength());
 empty = true;
 return chunk.getLength();
-
 }
 
+@Override
+public int available() {
+if (empty) {
+return 0;
+} else {
+return bodyBytes.getByteChunk().getLength();
+}
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/InputFilter.java 
b/java/org/apache/coyote/http11/InputFilter.java
index a90c88b..a854ffe 100644
--- a/java/org/apache/coyote/http11/InputFilter.java
+++ b/java/org/apache/coyote/http11/InputFilter.java
@@ -75,14 +75,5 @@ public interface InputFilter extends InputBuffer {
  * to consume extra bytes. The result of this method can't be negative (if
  * an error happens, an IOException should be thrown instead).
  */
-public long end()
-throws IOException;
-
-
-/**
- * Amount of bytes still available in a buffer.
- */
-public int available();
-
-
+public long end() throws IOException;
 }
diff --git a/java/org/apache/coyote/http11/InternalAprInputBuffer.java 
b/java/org/apache/coyote/http11/InternalAprInputBuffer.java
index 6f153a9..3921015 100644
--- a/java/org/apache/coyote/http11/InternalAprInputBuffer.java
+++ b/java/org/apache/coyote/http11/InternalAprInputBuffer.java
@@ -686,14 +686,11 @@ public class InternalAprInputBuffer extends 
AbstractInputBuffer {
 
 // - InputStreamInputBuffer Inner Class
 
-
 /**
  * This class is an input buffer which will read its data from an input
  * stream.
  */
-protected class SocketInputBuffer
-implements InputBuffer {
-
+protected class SocketInputBuffer implements InputBuffer {
 
 /**
  * Read bytes into the specified chunk.
@@ -713,5 +710,14 @@ public class InternalAprInputBuffer extends 
AbstractInputBuffer {
 
 return (length);
 }
+
+@Override
+pub

[tomcat] branch 9.0.x updated: Check empty flag when calculating available bytes

[markt]

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 47157c4  Check empty flag when calculating available bytes
47157c4 is described below

commit 47157c416c73dff5d461a81830b2836c47605e1e
Author: Mark Thomas 
AuthorDate: Wed Jul 8 23:53:03 2020 +0100

Check empty flag when calculating available bytes
---
 java/org/apache/coyote/ajp/AjpProcessor.java | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index 730cbd1..fb1b850 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1304,7 +1304,11 @@ public class AjpProcessor extends AbstractProcessor {
 
 @Override
 public int available() {
-return bodyBytes.getByteChunk().getLength();
+if (empty) {
+return 0;
+} else {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 }
 


-
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: Check empty flag when calculating available bytes

[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 452081a  Check empty flag when calculating available bytes
452081a is described below

commit 452081a4b236f7afb64acfe74ded5e3eea7b620f
Author: Mark Thomas 
AuthorDate: Wed Jul 8 23:53:03 2020 +0100

Check empty flag when calculating available bytes
---
 java/org/apache/coyote/ajp/AjpProcessor.java | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index 43e7366..4a297f5 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1458,7 +1458,11 @@ public class AjpProcessor extends AbstractProcessor {
 
 @Override
 public int available() {
-return bodyBytes.getByteChunk().getLength();
+if (empty) {
+return 0;
+} else {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 }
 


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

[tomcat] branch master updated: Check empty flag when calculating available bytes

[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 4eab935  Check empty flag when calculating available bytes
4eab935 is described below

commit 4eab93529f994b6df36c9c9898793973efde2083
Author: Mark Thomas 
AuthorDate: Wed Jul 8 23:53:03 2020 +0100

Check empty flag when calculating available bytes
---
 java/org/apache/coyote/ajp/AjpProcessor.java | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index 19752dd..c97f9b7 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1312,7 +1312,11 @@ public class AjpProcessor extends AbstractProcessor {
 
 @Override
 public int available() {
-return bodyBytes.getByteChunk().getLength();
+if (empty) {
+return 0;
+} else {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 }
 


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

buildbot failure in on tomcat-9-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-9-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-9-trunk/builds/329

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' 
triggered this build
Build Source Stamp: [branch 9.0.x] 1dc65035904b835b5e7a37eb43da4a76c2035509
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

[ANN] ApacheCon NA 2020 is virtual/online, completely free to attend, and call-for-presentations is OPEN!

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

[Cross-posting to dev@, please reply to users@]

ApacheCon NA 2020 is now "ApacheCon @Home" due to the COVID-19
pandemic, and will be held online 29 September - 1 October 2020. This
is a great opportunity for anyone who has never attended an ApacheCon
event to make this year their first ApacheCon. Registration is FREE
(zero-cost).

For those who have never given a presentation at ApacheCon, this is
also an opportunity for you to submit a presentation for our
consideration: the call-for-papers is open and the Tomcat track is
hoping to fill something like 12 - 36 hours worth of presentations,
panels, and meet-ups at this conference.

To register to attend or respond to the call-for-presentations, please
visit https://www.apachecon.com/acna2020/

Because the conference is being held online, obviously things will be
a little different than previous events. First, all presentations will
be streamed live and recorded for later replay if you can't make a
live-streaming event. "Attendance" for a live presentation would mean
streaming audio/video and at least a text channel by which questions
can be asked. I don't believe video is supported for attendees (to see
e.g. attendees faces) but it may be possible to ask questions via
audio instead text. I will follow-up with the organizers regarding
audience participation.

To accommodate attendees (and presenters!) in various time-zones
around the world, we will be attempting to schedule live presentations
in 4-hour blocks at 3 different daily intervals throughout the 72-hour
event.

My goal is to encourage each speaker to present their material live
/twice/ during the event, once in each of two separate
timezone-centric blocks (e.g. North/South America, Europe/Africa,
Asia/Oceana) if at all possible, and for several committers to be
available to "staff" each presentation to introduce speakers, provide
moderation of questions from the live-audience for the speakers, etc.

Schedules will be announced after the presentations have been selected
and everything is negotiated with the speakers about when they are
available.

If you are already considering submitting a presentation for including
in ApacheCon 2020, please head-over to the CFP at
https://www.apachecon.com/acna2020/

If you aren't sure if you are interested in presenting, or aren't sure
if you have the experience, knowledge, etc. to warrant a position as a
speaker, please consider the following:

1. This is a welcoming community
2. This community exists to serve YOU
3. You are a part of this community
4. Helping others within the community encourages others to do the same
5. If you'd prefer to pre-record your presentation, we can handle that
6. Topics can be very wide-ranging. Here are some examples of
presentations from previous ApacheCon events:

  [From Committers / directly about Tomcat]
  - Running Apache Tomcat on GraalVM
  - Tomcat in clusters and clouds
  - Using Let's Encrypt with Tomcat
  - Securing Tomcat
  - Reverse-proxying Tomcat
  - Load balancing with Tomcat
  - Clustering with Tomcat

  [From Non-Committers or not directly about Tomcat]
  - Packaging Tomcat for Linux Distributions
  - I Love Lucee -- a Java implementation of Cold Fusion
  - Routing CDN traffic at scale using Tomcat
  - Secure Web Applications using Apache Fortress
  - Monitoring Tomcat; various tools
  - Building Reactive Applications on Tomcat
  - Troubleshooting performance using thread dumps
  - High Throughput Production Systems on Tomcat
  - Why I Love Open Source
  - Introduction to Spring Boot
  - Tomcat, TomEE, and Meecrowave

  If you are using Tomcat at $work and doing something interesting,
we'd love to hear about it.

7. You don't need to be the foremost expert in $feature to talk about it
8. We are actively looking for speakers to talk about these and other
topics:

  - How to get started hacking on Tomcat ("How can I help?")
  - Running a "split" Tomcat installation (BASE vs HOME) for easy
upgrades
  - Deploying Tomcat in an auto-scaling environment (e.g. AWS EBS)
  - Tomcat should really have [Feature X]
  - Whatever you think might be interesting!

Please consider speaking if you haven't done so before. If you are
worried about whether your idea is good enough: don't. Just submit
your idea to the CFP -- you don't have to write-up the presentation in
order to submit an idea, just write a paragraph or two about what you
want to do -- and the track chairpersons (chairpeople?[1]) will decide
whether or not to include your presentation in the event. (And chances
are good that if you submit an idea it will be accepted.)

Please reply to the users list with any questions you may have about
ApacheCon, the Tomcat track, or submitting a talk proposal.

Thanks,
- -chris

On behalf of all ApacheCon 2020 Tomcat Track chairpersons


[1]
https://vignette.wikia.nocookie.net/rickandmorty/images/c/cd/Furniture.p
ng/revision/latest/scale-to-width-down/1000?cb=20160910223642
-

[tomcat] branch 8.5.x updated: Refactor sis.available() for more accurate return value

[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 42a1b21  Refactor sis.available() for more accurate return value
42a1b21 is described below

commit 42a1b2158be9f774e0c86f318f5b207c7b0d4c46
Author: Mark Thomas 
AuthorDate: Mon Jul 6 19:33:00 2020 +0100

Refactor sis.available() for more accurate return value
---
 java/org/apache/coyote/InputBuffer.java| 11 
 java/org/apache/coyote/ajp/AjpProcessor.java   |  7 -
 .../apache/coyote/http11/Http11InputBuffer.java| 30 +++---
 java/org/apache/coyote/http11/InputFilter.java |  8 --
 .../coyote/http11/filters/BufferedInputFilter.java |  8 +-
 .../coyote/http11/filters/ChunkedInputFilter.java  | 11 +++-
 .../coyote/http11/filters/IdentityInputFilter.java |  3 ++-
 java/org/apache/coyote/http2/Stream.java   |  3 ++-
 webapps/docs/changelog.xml |  9 +++
 9 files changed, 68 insertions(+), 22 deletions(-)

diff --git a/java/org/apache/coyote/InputBuffer.java 
b/java/org/apache/coyote/InputBuffer.java
index b2f9d09..c403315 100644
--- a/java/org/apache/coyote/InputBuffer.java
+++ b/java/org/apache/coyote/InputBuffer.java
@@ -61,4 +61,15 @@ public interface InputBuffer {
  * @throws IOException If an I/O error occurs reading from the input stream
  */
 public int doRead(ApplicationBufferHandler handler) throws IOException;
+
+
+/**
+ * Obtain an estimate of the number of bytes that can be read without
+ * blocking. Typically, this will be the number of available bytes known to
+ * be buffered.
+ *
+ * @return The number of bytes that can be read without blocking
+ */
+public int available();
+
 }
diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index e65486d..43e7366 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1189,7 +1189,7 @@ public class AjpProcessor extends AbstractProcessor {
 if (empty) {
 return 0;
 } else {
-return bodyBytes.getByteChunk().getLength();
+return request.getInputBuffer().available();
 }
 }
 
@@ -1455,6 +1455,11 @@ public class AjpProcessor extends AbstractProcessor {
 empty = true;
 return handler.getByteBuffer().remaining();
 }
+
+@Override
+public int available() {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java 
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index fe9cc96..a3f9a46 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -257,12 +257,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 @Override
 public int doRead(ApplicationBufferHandler handler) throws IOException {
-
-if (lastActiveFilter == -1)
+if (lastActiveFilter == -1) {
 return inputStreamInputBuffer.doRead(handler);
-else
+} else {
 return activeFilters[lastActiveFilter].doRead(handler);
-
+}
 }
 
 
@@ -662,17 +661,25 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 }
 
 
+@Override
+public int available() {
+return available(false);
+}
+
+
 /**
  * Available bytes in the buffers (note that due to encoding, this may not
  * correspond).
  */
 int available(boolean read) {
-int available = byteBuffer.remaining();
-if ((available == 0) && (lastActiveFilter >= 0)) {
-for (int i = 0; (available == 0) && (i <= lastActiveFilter); i++) {
-available = activeFilters[i].available();
-}
+int available;
+
+if (lastActiveFilter == -1) {
+available = inputStreamInputBuffer.available();
+} else {
+available = activeFilters[lastActiveFilter].available();
 }
+
 if (available > 0 || !read) {
 return available;
 }
@@ -1161,6 +1168,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 return length;
 }
+
+@Override
+public int available() {
+return byteBuffer.remaining();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/InputFilter.java 
b/java/org/apache/coyote/http11/InputFilter.java
index 0d15490..a36c528 100644
--- a/java/org/apache/coyote/http11/InputFilter.java
+++ b/java/org/apache/coyote/http11/InputFilter.java
@@ -76,14 +76,6 @@ public interface InputFilter extends InputBuffer {
 
 
 /**
- * Amount of

[tomcat] branch 9.0.x updated: Refactor sis.available() for more accurate return value

[markt]

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 1dc6503  Refactor sis.available() for more accurate return value
1dc6503 is described below

commit 1dc65035904b835b5e7a37eb43da4a76c2035509
Author: Mark Thomas 
AuthorDate: Mon Jul 6 19:33:00 2020 +0100

Refactor sis.available() for more accurate return value
---
 java/org/apache/coyote/InputBuffer.java| 11 
 java/org/apache/coyote/ajp/AjpProcessor.java   |  7 -
 .../apache/coyote/http11/Http11InputBuffer.java| 30 +++---
 java/org/apache/coyote/http11/InputFilter.java |  8 --
 .../coyote/http11/filters/BufferedInputFilter.java |  8 +-
 .../coyote/http11/filters/ChunkedInputFilter.java  | 11 +++-
 .../coyote/http11/filters/IdentityInputFilter.java |  3 ++-
 java/org/apache/coyote/http2/Stream.java   |  3 ++-
 webapps/docs/changelog.xml |  9 +++
 9 files changed, 68 insertions(+), 22 deletions(-)

diff --git a/java/org/apache/coyote/InputBuffer.java 
b/java/org/apache/coyote/InputBuffer.java
index e30a51e..e836ee4 100644
--- a/java/org/apache/coyote/InputBuffer.java
+++ b/java/org/apache/coyote/InputBuffer.java
@@ -41,4 +41,15 @@ public interface InputBuffer {
  * @throws IOException If an I/O error occurs reading from the input stream
  */
 public int doRead(ApplicationBufferHandler handler) throws IOException;
+
+
+/**
+ * Obtain an estimate of the number of bytes that can be read without
+ * blocking. Typically, this will be the number of available bytes known to
+ * be buffered.
+ *
+ * @return The number of bytes that can be read without blocking
+ */
+public int available();
+
 }
diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index 88f1cb7..730cbd1 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1079,7 +1079,7 @@ public class AjpProcessor extends AbstractProcessor {
 if (empty) {
 return 0;
 } else {
-return bodyBytes.getByteChunk().getLength();
+return request.getInputBuffer().available();
 }
 }
 
@@ -1301,6 +1301,11 @@ public class AjpProcessor extends AbstractProcessor {
 empty = true;
 return handler.getByteBuffer().remaining();
 }
+
+@Override
+public int available() {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java 
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 181d631..71ba804 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -242,12 +242,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 @Override
 public int doRead(ApplicationBufferHandler handler) throws IOException {
-
-if (lastActiveFilter == -1)
+if (lastActiveFilter == -1) {
 return inputStreamInputBuffer.doRead(handler);
-else
+} else {
 return activeFilters[lastActiveFilter].doRead(handler);
-
+}
 }
 
 
@@ -648,17 +647,25 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 }
 
 
+@Override
+public int available() {
+return available(false);
+}
+
+
 /**
  * Available bytes in the buffers (note that due to encoding, this may not
  * correspond).
  */
 int available(boolean read) {
-int available = byteBuffer.remaining();
-if ((available == 0) && (lastActiveFilter >= 0)) {
-for (int i = 0; (available == 0) && (i <= lastActiveFilter); i++) {
-available = activeFilters[i].available();
-}
+int available;
+
+if (lastActiveFilter == -1) {
+available = inputStreamInputBuffer.available();
+} else {
+available = activeFilters[lastActiveFilter].available();
 }
+
 if (available > 0 || !read) {
 return available;
 }
@@ -1140,6 +1147,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 return length;
 }
+
+@Override
+public int available() {
+return byteBuffer.remaining();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/InputFilter.java 
b/java/org/apache/coyote/http11/InputFilter.java
index 0d15490..a36c528 100644
--- a/java/org/apache/coyote/http11/InputFilter.java
+++ b/java/org/apache/coyote/http11/InputFilter.java
@@ -76,14 +76,6 @@ public interface InputFilter extends InputBuffer {
 
 
 /**
- * Amount of

buildbot failure in on tomcat-7-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1737

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] 53f104ffd2e701a2a74500f690725c36b5e08217
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

[tomcat] branch master updated: Refactor sis.available() for more accurate return value

[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 15725e7  Refactor sis.available() for more accurate return value
15725e7 is described below

commit 15725e7569efd91debfaaf75e99e8f88e0be9a36
Author: Mark Thomas 
AuthorDate: Mon Jul 6 19:33:00 2020 +0100

Refactor sis.available() for more accurate return value
---
 java/org/apache/coyote/InputBuffer.java| 11 
 java/org/apache/coyote/ajp/AjpProcessor.java   |  7 -
 .../apache/coyote/http11/Http11InputBuffer.java| 30 +++---
 java/org/apache/coyote/http11/InputFilter.java |  8 --
 .../coyote/http11/filters/BufferedInputFilter.java |  8 +-
 .../coyote/http11/filters/ChunkedInputFilter.java  | 11 +++-
 .../coyote/http11/filters/IdentityInputFilter.java |  3 ++-
 java/org/apache/coyote/http2/Stream.java   |  3 ++-
 webapps/docs/changelog.xml |  5 
 9 files changed, 64 insertions(+), 22 deletions(-)

diff --git a/java/org/apache/coyote/InputBuffer.java 
b/java/org/apache/coyote/InputBuffer.java
index e30a51e..e836ee4 100644
--- a/java/org/apache/coyote/InputBuffer.java
+++ b/java/org/apache/coyote/InputBuffer.java
@@ -41,4 +41,15 @@ public interface InputBuffer {
  * @throws IOException If an I/O error occurs reading from the input stream
  */
 public int doRead(ApplicationBufferHandler handler) throws IOException;
+
+
+/**
+ * Obtain an estimate of the number of bytes that can be read without
+ * blocking. Typically, this will be the number of available bytes known to
+ * be buffered.
+ *
+ * @return The number of bytes that can be read without blocking
+ */
+public int available();
+
 }
diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java 
b/java/org/apache/coyote/ajp/AjpProcessor.java
index 77d6a94..19752dd 100644
--- a/java/org/apache/coyote/ajp/AjpProcessor.java
+++ b/java/org/apache/coyote/ajp/AjpProcessor.java
@@ -1087,7 +1087,7 @@ public class AjpProcessor extends AbstractProcessor {
 if (empty) {
 return 0;
 } else {
-return bodyBytes.getByteChunk().getLength();
+return request.getInputBuffer().available();
 }
 }
 
@@ -1309,6 +1309,11 @@ public class AjpProcessor extends AbstractProcessor {
 empty = true;
 return handler.getByteBuffer().remaining();
 }
+
+@Override
+public int available() {
+return bodyBytes.getByteChunk().getLength();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/Http11InputBuffer.java 
b/java/org/apache/coyote/http11/Http11InputBuffer.java
index 8619a32..822558f0 100644
--- a/java/org/apache/coyote/http11/Http11InputBuffer.java
+++ b/java/org/apache/coyote/http11/Http11InputBuffer.java
@@ -242,12 +242,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 @Override
 public int doRead(ApplicationBufferHandler handler) throws IOException {
-
-if (lastActiveFilter == -1)
+if (lastActiveFilter == -1) {
 return inputStreamInputBuffer.doRead(handler);
-else
+} else {
 return activeFilters[lastActiveFilter].doRead(handler);
-
+}
 }
 
 
@@ -648,17 +647,25 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 }
 
 
+@Override
+public int available() {
+return available(false);
+}
+
+
 /**
  * Available bytes in the buffers (note that due to encoding, this may not
  * correspond).
  */
 int available(boolean read) {
-int available = byteBuffer.remaining();
-if ((available == 0) && (lastActiveFilter >= 0)) {
-for (int i = 0; (available == 0) && (i <= lastActiveFilter); i++) {
-available = activeFilters[i].available();
-}
+int available;
+
+if (lastActiveFilter == -1) {
+available = inputStreamInputBuffer.available();
+} else {
+available = activeFilters[lastActiveFilter].available();
 }
+
 if (available > 0 || !read) {
 return available;
 }
@@ -1140,6 +1147,11 @@ public class Http11InputBuffer implements InputBuffer, 
ApplicationBufferHandler
 
 return length;
 }
+
+@Override
+public int available() {
+return byteBuffer.remaining();
+}
 }
 
 
diff --git a/java/org/apache/coyote/http11/InputFilter.java 
b/java/org/apache/coyote/http11/InputFilter.java
index 0d15490..a36c528 100644
--- a/java/org/apache/coyote/http11/InputFilter.java
+++ b/java/org/apache/coyote/http11/InputFilter.java
@@ -76,14 +76,6 @@ public interface InputFilter extends InputBuffer {
 
 
 /**
- * Amount of

Re: Improving SameSite support

[Rémy Maucherat]

On Wed, Jul 8, 2020 at 8:55 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rémy,
>
> On 7/8/20 11:47, Rémy Maucherat wrote:
> > On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz
> >  > >
> wrote:
> >
> > Rémy,
> >
> > On 7/8/20 10:35, Rémy Maucherat wrote:
> >> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
> >>  >> 
> >>  > >> wrote:
> >
>  Clearly, no, with multiple elements, the digester rules
>  added to ContextRuleSet would be something like (in addition
>  to the unchanged ones for CookieProcessor):
> >>>
> >>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
> >>>
>  "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
> >>> "className"); digester.addSetProperties(prefix +
> >>> "Context/CookieProcessor"); digester.addSetNext(prefix +
> >>> "Context/CookieProcessor", "setCookieProcessor",
> >>> "org.apache.tomcat.util.http.CookieProcessor");
> >>>
> >>> digester.addObjectCreate(prefix +
>  "Context/CookieProcessor/SameSiteCookie",
> >>>
>  "org.apache.tomcat.util.http.SameSiteCookie",
> >>> "className"); digester.addSetProperties(prefix +
>  "Context/CookieProcessor/SameSiteCookie");
> >>> digester.addSetNext(prefix +
>  "Context/CookieProcessor/SameSiteCookie",
> >>> "addSameSiteCookie",
> >>> "org.apache.tomcat.util.http.SameSiteCookie");
> >>>
>  If the bean class is
>  org.apache.tomcat.util.http.SameSiteCookie.
> >
> >> So you are okay with:
> >
> >> digester.addSetProperties(prefix +
> >> "Context/CookieProcessor/SameSiteCookie");
> >
> >
> >> But not with:
> >
> >> digester.addCallMethod(prefix +
> >> "Context/CookieProcessor/SameSiteCookie/Cookie");
> >
> >> ?
> >
> >
> >> The digester works best with beans so I don't see what is so
> >> surprising about this.
> >
> > What's surprising is that you are -1 to what I see as an
> > improvement to Tomcat without much in the way of disruption. I
> > think it's pretty clean.
> >
> > Would proposing an actual patch help, or will you still be -1 on
> > anything other than a complicated "sameSiteCookies" string value
> > which needs to be unpacked by Tomcat code rather than using
> > standard XML element/attribute syntax?
> >
> >
> >> The digester rules I posted add a new SameSiteCookie element I
> >> only>> mentioned a complex sameSiteCookies attribute syntax once
> >> (I considered it would be better for API compatibility; the
> >> CookieProcessor API should not break in Tomcat 9 when things are
> >> backported, or the feature would be limited to Tomcat 10) but I
> >> didn't mention it again since you did not like it.
>
> I can't tell you if you are saying you'd be -1 to add that new
> SameSiteCookie element (because it is "too big a change", or because
> it requires "changes to digester configuration"), or that you are -1
> to use digester.addCallMethod (because you don't like it), or that you
> are -1 to really supporting any improvements to SameSite at all.
>
> Can you clarify?
>

Ok, another attempt then.

A SameSiteCookie element can be added using the following extra rules in
ContextRuleSet:

digester.addObjectCreate(prefix +
"Context/CookieProcessor/SameSiteCookie",

 "org.apache.tomcat.util.http.SameSiteCookie",
 "className");
digester.addSetProperties(prefix +
"Context/CookieProcessor/SameSiteCookie");
digester.addSetNext(prefix +
"Context/CookieProcessor/SameSiteCookie",
"addSameSiteCookie",
"org.apache.tomcat.util.http.SameSiteCookie");

Other ways to add the element to server.xml don't work as well. It also
keeps the embedded API consistent and storeconfig is likely the usual cut
and paste.

Then I'm wondering about compatibility with the current CookieProcessor
interface. If it's not compatible, the change would de facto be limited to
Tomcat 10.


> I won't waste my time if you are going to -1 anything I do, here.
>

I don't understand what was hard to understand in this case. Anyway, I had
to pull quite a few ideas in the past personally, often due to a "it would
break something" problem.

Rémy


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8GFogACgkQHPApP6U8
> pFg1UQ/+M9SU2f9YkLUnRU0f2MqdIwKFguLHFfFxZSnxoEOhIVJOmJbm5YrZlwIv
> skzgJiPvX7wMWfq0wO8mc/ALjOAn/XhEE66sIWZe9bc9Hte0mrXHV8wmHZXhTW+O
> LqLNGJgXH/m8Mxui27h2EfpRXYDEKEGLUU71j3NMOxd6xa0xfYv/MiBI3asMZpvQ
> k688fWGa4EeoTj4yRtR+eIOYpcPFZlaT+uNFGPNr7HVMvSB0SAx/Ui732bMEXpRT
> 2CRaPSZ4TAFBhZLNXxfBodErGWA6QHQPgnPgB0oPbCM78R0zldVyXLMRpksZL/V7
> Dx6cJE/Da7fISufomcMsdrpFmQ3LylXbKNTdbkzlDT9hdpgSn7kc4tDYJzwTt0NS
> K2/fbi8gQOEg7VB6pRVeXxODhEovFizEKfuGhwFNyuw7q0cxK+w6W+zFdu+wgcj/
> Epa/XDmtuKz5doG

[tomcat] branch 7.0.x updated: Log additional information when a WebSocket connection fails

[markt]

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 53f104f  Log additional information when a WebSocket connection fails
53f104f is described below

commit 53f104ffd2e701a2a74500f690725c36b5e08217
Author: Mark Thomas 
AuthorDate: Wed Jul 8 21:42:42 2020 +0100

Log additional information when a WebSocket connection fails

This is primarily to help debug a relatively rare CI failure in
TestWebSocketFrameClient.testConnectToRootEndpoint()
---
 java/org/apache/tomcat/websocket/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/websocket/WsWebSocketContainer.java | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/websocket/LocalStrings.properties 
b/java/org/apache/tomcat/websocket/LocalStrings.properties
index 0659225..0888576 100644
--- a/java/org/apache/tomcat/websocket/LocalStrings.properties
+++ b/java/org/apache/tomcat/websocket/LocalStrings.properties
@@ -132,6 +132,7 @@ wsWebSocketContainer.pathNoHost=No host was specified in URI
 wsWebSocketContainer.pathWrongScheme=The scheme [{0}] is not supported. The 
supported schemes are ws and wss
 wsWebSocketContainer.proxyConnectFail=Failed to connect to the configured 
Proxy [{0}]. The HTTP response code was [{1}]
 wsWebSocketContainer.redirectThreshold=Cyclic Location header [{0}] detected / 
reached max number of redirects [{1}] of max [{2}]
+wsWebSocketContainer.responseFail=The HTTP upgrade to WebSocket failed but 
partial data may have been received: Status Code [{0}], HTTP headers [{1}]
 wsWebSocketContainer.sessionCloseFail=Session with ID [{0}] did not close 
cleanly
 wsWebSocketContainer.sslEngineFail=Unable to create SSLEngine to support 
SSL/TLS connections
 wsWebSocketContainer.unsupportedAuthScheme=Failed to handle HTTP response code 
[{0}]. Unsupported Authentication scheme [{1}] returned in response
diff --git a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java 
b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
index b4cbe34..a59296c 100644
--- a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
+++ b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
@@ -858,9 +858,17 @@ public class WsWebSocketContainer
 response.clear();
 // Blocking read
 Future read = channel.read(response);
-Integer bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+Integer bytesRead;
+try {
+bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+} catch (TimeoutException e) {
+TimeoutException te = new TimeoutException(
+sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
+te.initCause(e);
+throw te;
+}
 if (bytesRead.intValue() == -1) {
-throw new EOFException();
+throw new 
EOFException(sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
 }
 response.flip();
 while (response.hasRemaining() && !readHeaders) {


-
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: Log additional information when a WebSocket connection fails

[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 13a9bb1  Log additional information when a WebSocket connection fails
13a9bb1 is described below

commit 13a9bb1abd2e8895d6bb5c783586c377fc78f099
Author: Mark Thomas 
AuthorDate: Wed Jul 8 21:42:42 2020 +0100

Log additional information when a WebSocket connection fails

This is primarily to help debug a relatively rare CI failure in
TestWebSocketFrameClient.testConnectToRootEndpoint()
---
 java/org/apache/tomcat/websocket/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/websocket/WsWebSocketContainer.java | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/websocket/LocalStrings.properties 
b/java/org/apache/tomcat/websocket/LocalStrings.properties
index 929822d..8c3c505 100644
--- a/java/org/apache/tomcat/websocket/LocalStrings.properties
+++ b/java/org/apache/tomcat/websocket/LocalStrings.properties
@@ -142,6 +142,7 @@ wsWebSocketContainer.pathNoHost=No host was specified in URI
 wsWebSocketContainer.pathWrongScheme=The scheme [{0}] is not supported. The 
supported schemes are ws and wss
 wsWebSocketContainer.proxyConnectFail=Failed to connect to the configured 
Proxy [{0}]. The HTTP response code was [{1}]
 wsWebSocketContainer.redirectThreshold=Cyclic Location header [{0}] detected / 
reached max number of redirects [{1}] of max [{2}]
+wsWebSocketContainer.responseFail=The HTTP upgrade to WebSocket failed but 
partial data may have been received: Status Code [{0}], HTTP headers [{1}]
 wsWebSocketContainer.sessionCloseFail=Session with ID [{0}] did not close 
cleanly
 wsWebSocketContainer.sslEngineFail=Unable to create SSLEngine to support 
SSL/TLS connections
 wsWebSocketContainer.unsupportedAuthScheme=Failed to handle HTTP response code 
[{0}]. Unsupported Authentication scheme [{1}] returned in response
diff --git a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java 
b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
index 67c507a..98c1a8d 100644
--- a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
+++ b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
@@ -800,9 +800,17 @@ public class WsWebSocketContainer implements 
WebSocketContainer, BackgroundProce
 response.clear();
 // Blocking read
 Future read = channel.read(response);
-Integer bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+Integer bytesRead;
+try {
+bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+} catch (TimeoutException e) {
+TimeoutException te = new TimeoutException(
+sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
+te.initCause(e);
+throw te;
+}
 if (bytesRead.intValue() == -1) {
-throw new EOFException();
+throw new 
EOFException(sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
 }
 response.flip();
 while (response.hasRemaining() && !readHeaders) {


-
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: Log additional information when a WebSocket connection fails

[markt]

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 354  Log additional information when a WebSocket connection fails
354 is described below

commit 354070eb7fb68463af64dcde72258bd25aa3
Author: Mark Thomas 
AuthorDate: Wed Jul 8 21:42:42 2020 +0100

Log additional information when a WebSocket connection fails

This is primarily to help debug a relatively rare CI failure in
TestWebSocketFrameClient.testConnectToRootEndpoint()
---
 java/org/apache/tomcat/websocket/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/websocket/WsWebSocketContainer.java | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/websocket/LocalStrings.properties 
b/java/org/apache/tomcat/websocket/LocalStrings.properties
index 929822d..8c3c505 100644
--- a/java/org/apache/tomcat/websocket/LocalStrings.properties
+++ b/java/org/apache/tomcat/websocket/LocalStrings.properties
@@ -142,6 +142,7 @@ wsWebSocketContainer.pathNoHost=No host was specified in URI
 wsWebSocketContainer.pathWrongScheme=The scheme [{0}] is not supported. The 
supported schemes are ws and wss
 wsWebSocketContainer.proxyConnectFail=Failed to connect to the configured 
Proxy [{0}]. The HTTP response code was [{1}]
 wsWebSocketContainer.redirectThreshold=Cyclic Location header [{0}] detected / 
reached max number of redirects [{1}] of max [{2}]
+wsWebSocketContainer.responseFail=The HTTP upgrade to WebSocket failed but 
partial data may have been received: Status Code [{0}], HTTP headers [{1}]
 wsWebSocketContainer.sessionCloseFail=Session with ID [{0}] did not close 
cleanly
 wsWebSocketContainer.sslEngineFail=Unable to create SSLEngine to support 
SSL/TLS connections
 wsWebSocketContainer.unsupportedAuthScheme=Failed to handle HTTP response code 
[{0}]. Unsupported Authentication scheme [{1}] returned in response
diff --git a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java 
b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
index 70bc4ca..702c866 100644
--- a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
+++ b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
@@ -800,9 +800,17 @@ public class WsWebSocketContainer implements 
WebSocketContainer, BackgroundProce
 response.clear();
 // Blocking read
 Future read = channel.read(response);
-Integer bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+Integer bytesRead;
+try {
+bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+} catch (TimeoutException e) {
+TimeoutException te = new TimeoutException(
+sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
+te.initCause(e);
+throw te;
+}
 if (bytesRead.intValue() == -1) {
-throw new EOFException();
+throw new 
EOFException(sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
 }
 response.flip();
 while (response.hasRemaining() && !readHeaders) {


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

[tomcat] branch master updated: Log additional information when a WebSocket connection fails

[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 c46bbc3  Log additional information when a WebSocket connection fails
c46bbc3 is described below

commit c46bbc3a9320aa25dc5e5cd3d124f596e57b4370
Author: Mark Thomas 
AuthorDate: Wed Jul 8 21:42:42 2020 +0100

Log additional information when a WebSocket connection fails

This is primarily to help debug a relatively rare CI failure in
TestWebSocketFrameClient.testConnectToRootEndpoint()
---
 java/org/apache/tomcat/websocket/LocalStrings.properties   |  1 +
 java/org/apache/tomcat/websocket/WsWebSocketContainer.java | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/tomcat/websocket/LocalStrings.properties 
b/java/org/apache/tomcat/websocket/LocalStrings.properties
index 929822d..8c3c505 100644
--- a/java/org/apache/tomcat/websocket/LocalStrings.properties
+++ b/java/org/apache/tomcat/websocket/LocalStrings.properties
@@ -142,6 +142,7 @@ wsWebSocketContainer.pathNoHost=No host was specified in URI
 wsWebSocketContainer.pathWrongScheme=The scheme [{0}] is not supported. The 
supported schemes are ws and wss
 wsWebSocketContainer.proxyConnectFail=Failed to connect to the configured 
Proxy [{0}]. The HTTP response code was [{1}]
 wsWebSocketContainer.redirectThreshold=Cyclic Location header [{0}] detected / 
reached max number of redirects [{1}] of max [{2}]
+wsWebSocketContainer.responseFail=The HTTP upgrade to WebSocket failed but 
partial data may have been received: Status Code [{0}], HTTP headers [{1}]
 wsWebSocketContainer.sessionCloseFail=Session with ID [{0}] did not close 
cleanly
 wsWebSocketContainer.sslEngineFail=Unable to create SSLEngine to support 
SSL/TLS connections
 wsWebSocketContainer.unsupportedAuthScheme=Failed to handle HTTP response code 
[{0}]. Unsupported Authentication scheme [{1}] returned in response
diff --git a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java 
b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
index dbe4c12..c78da3c 100644
--- a/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
+++ b/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
@@ -801,9 +801,17 @@ public class WsWebSocketContainer implements 
WebSocketContainer, BackgroundProce
 response.clear();
 // Blocking read
 Future read = channel.read(response);
-Integer bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+Integer bytesRead;
+try {
+bytesRead = read.get(timeout, TimeUnit.MILLISECONDS);
+} catch (TimeoutException e) {
+TimeoutException te = new TimeoutException(
+sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
+te.initCause(e);
+throw te;
+}
 if (bytesRead.intValue() == -1) {
-throw new EOFException();
+throw new 
EOFException(sm.getString("wsWebSocketContainer.responseFail", 
Integer.toString(status), headers));
 }
 response.flip();
 while (response.hasRemaining() && !readHeaders) {


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

Re: Improving SameSite support

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 11:47, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz
>  >
wrote:
>
> Rémy,
>
> On 7/8/20 10:35, Rémy Maucherat wrote:
>> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>> > 
>>  >> wrote:
>
 Clearly, no, with multiple elements, the digester rules
 added to ContextRuleSet would be something like (in addition
 to the unchanged ones for CookieProcessor):
>>>
>>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>>
 "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>>> "Context/CookieProcessor", "setCookieProcessor",
>>> "org.apache.tomcat.util.http.CookieProcessor");
>>>
>>> digester.addObjectCreate(prefix +
 "Context/CookieProcessor/SameSiteCookie",
>>>
 "org.apache.tomcat.util.http.SameSiteCookie",
>>> "className"); digester.addSetProperties(prefix +
 "Context/CookieProcessor/SameSiteCookie");
>>> digester.addSetNext(prefix +
 "Context/CookieProcessor/SameSiteCookie",
>>> "addSameSiteCookie",
>>> "org.apache.tomcat.util.http.SameSiteCookie");
>>>
 If the bean class is
 org.apache.tomcat.util.http.SameSiteCookie.
>
>> So you are okay with:
>
>> digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
>
>
>> But not with:
>
>> digester.addCallMethod(prefix +
>> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
>> ?
>
>
>> The digester works best with beans so I don't see what is so
>> surprising about this.
>
> What's surprising is that you are -1 to what I see as an
> improvement to Tomcat without much in the way of disruption. I
> think it's pretty clean.
>
> Would proposing an actual patch help, or will you still be -1 on
> anything other than a complicated "sameSiteCookies" string value
> which needs to be unpacked by Tomcat code rather than using
> standard XML element/attribute syntax?
>
>
>> The digester rules I posted add a new SameSiteCookie element I
>> only>> mentioned a complex sameSiteCookies attribute syntax once
>> (I considered it would be better for API compatibility; the
>> CookieProcessor API should not break in Tomcat 9 when things are
>> backported, or the feature would be limited to Tomcat 10) but I
>> didn't mention it again since you did not like it.

I can't tell you if you are saying you'd be -1 to add that new
SameSiteCookie element (because it is "too big a change", or because
it requires "changes to digester configuration"), or that you are -1
to use digester.addCallMethod (because you don't like it), or that you
are -1 to really supporting any improvements to SameSite at all.

Can you clarify?

I won't waste my time if you are going to -1 anything I do, here.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8GFogACgkQHPApP6U8
pFg1UQ/+M9SU2f9YkLUnRU0f2MqdIwKFguLHFfFxZSnxoEOhIVJOmJbm5YrZlwIv
skzgJiPvX7wMWfq0wO8mc/ALjOAn/XhEE66sIWZe9bc9Hte0mrXHV8wmHZXhTW+O
LqLNGJgXH/m8Mxui27h2EfpRXYDEKEGLUU71j3NMOxd6xa0xfYv/MiBI3asMZpvQ
k688fWGa4EeoTj4yRtR+eIOYpcPFZlaT+uNFGPNr7HVMvSB0SAx/Ui732bMEXpRT
2CRaPSZ4TAFBhZLNXxfBodErGWA6QHQPgnPgB0oPbCM78R0zldVyXLMRpksZL/V7
Dx6cJE/Da7fISufomcMsdrpFmQ3LylXbKNTdbkzlDT9hdpgSn7kc4tDYJzwTt0NS
K2/fbi8gQOEg7VB6pRVeXxODhEovFizEKfuGhwFNyuw7q0cxK+w6W+zFdu+wgcj/
Epa/XDmtuKz5doGOnuwzpudf3For8rdVpdpmRUU7+1PiLX6xsj2cueY1ku7e45LL
ZR9cMGkW/sEU1oWw2HKM3fMqAuZEkFiNvYhua/KM6tVbqFXC49GeF+K+qe/zx2DK
W+xrPOnQ2A4viyLVAFbidPkxemdnp5VX+VXeXvgmCeRmsmWqvza73UJzf1Es4qg5
inLHbksUnsokixJHF2KwbsFFdubldl5HogNIpExmwwlb9Eg2fFI=
=j71t
-END PGP SIGNATURE-

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

[Bug 64583] org.apache.tomcat.websocket.pojo.TestEncodingDecoding / testAnnotatedEndPoints - testEvent fails occasionally

[bugzilla]

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

Konstantin Kolinko  changed:

   What|Removed |Added

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

--- Comment #9 from Konstantin Kolinko  ---
Testing current 7.0.x (at 4ac8e86347a6a82133354312e7eb8c1aa09bb129):

I had {(30 runs with Java 8, 60 runs with Java 11, 30 runs with Java 14) x all
3 connectors - on Windows 10}. No issues noted - Testing this test class
completes successfully.

Thus I marking this issue as RESOLVED.

-- 
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: Improving SameSite support

[Rémy Maucherat]

On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rémy,
>
> On 7/8/20 10:35, Rémy Maucherat wrote:
> > On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
> >  > > wrote:
> >
> >>> Clearly, no, with multiple elements, the digester rules added
> >>> to ContextRuleSet would be something like (in addition to the
> >>> unchanged ones for CookieProcessor):
> >>
> >> digester.addObjectCreate(prefix + "Context/CookieProcessor",
> >>
> >>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
> >> "className"); digester.addSetProperties(prefix +
> >> "Context/CookieProcessor"); digester.addSetNext(prefix +
> >> "Context/CookieProcessor", "setCookieProcessor",
> >> "org.apache.tomcat.util.http.CookieProcessor");
> >>
> >> digester.addObjectCreate(prefix +
> >>> "Context/CookieProcessor/SameSiteCookie",
> >>
> >>> "org.apache.tomcat.util.http.SameSiteCookie",
> >> "className"); digester.addSetProperties(prefix +
> >>> "Context/CookieProcessor/SameSiteCookie");
> >> digester.addSetNext(prefix +
> >>> "Context/CookieProcessor/SameSiteCookie",
> >> "addSameSiteCookie",
> >> "org.apache.tomcat.util.http.SameSiteCookie");
> >>
> >>> If the bean class is
> >>> org.apache.tomcat.util.http.SameSiteCookie.
> >
> > So you are okay with:
> >
> > digester.addSetProperties(prefix +
> > "Context/CookieProcessor/SameSiteCookie");
> >
> >
> > But not with:
> >
> > digester.addCallMethod(prefix +
> > "Context/CookieProcessor/SameSiteCookie/Cookie");
> >
> > ?
> >
> >
> > The digester works best with beans so I don't see what is so
> > surprising about this.
>
> What's surprising is that you are -1 to what I see as an improvement
> to Tomcat without much in the way of disruption. I think it's pretty
> clean.
>
> Would proposing an actual patch help, or will you still be -1 on
> anything other than a complicated "sameSiteCookies" string value which
> needs to be unpacked by Tomcat code rather than using standard XML
> element/attribute syntax?
>

The digester rules I posted add a new SameSiteCookie element. I only
mentioned a complex sameSiteCookies attribute syntax once (I considered it
would be better for API compatibility; the CookieProcessor API should not
break in Tomcat 9 when things are backported, or the feature would be
limited to Tomcat 10) but I didn't mention it again since you did not like
it.

Rémy


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F4eMACgkQHPApP6U8
> pFhhkxAAgQdr7vdbaO0qeWHPbKdh2hcy5NuKMOozOWaERHowTsx3yv9rHfiVKaXG
> gti6mzcLIqXMPiMbqCE+fYpOCAfqJsAtjjg3zWs9Sh1vk7HOrOmZ7V2s5bbvjeqe
> zCcrgdC+PKMO9Up/OWdwfAj8oARhtYFfTQfgoEiT61ElDYNnCU+swuDh9CZwJpv0
> HzQ+U+kEEYpgZrawzuk4xCvOSk+HKNAcG5LDphYgLUGUNg3Eq7tlvzDSQ/PX1Hbd
> VFHipCk4pDcRgvFq9GYK3b81QAlxcizFOW129+CPRSYINg1ztomv1Gqw+JXiwnG5
> YCcd6LaBT0fn3SldtE/rWNZResK3qnQG0aeAFvdl1qzzWvOSMMzyuJB7XMxkRlTZ
> lo3w7nJ9dJ4RdtjSshuBj6vrjFxqmAexbhy+e/aWmjKjjuEPl9oZx7jYbGKg79ER
> Bn+6nkUEP7YxBMSg9LTqFJvzGw6PPplunn6MTef7PZYpj9qwJh5xg2AXGZqrndmD
> XaowT4zNASfguq34BxmACWkqQrc6+3Wvdutafz7yvr0yxrvZz2+pmT6fJ9C6nBQO
> 4xyqxYRUa+Bt+4b2ppAzrVIJ+egk+6tbcUiqxMvbH1RV7GD+rwyEI5DRtv1RsTiw
> lCI9Y4K3R2a1pEN/0nArQrkBAzEttlxTPoZ9eJyUxsuVXtLor6g=
> =lUHF
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

buildbot success in on tomcat-9-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-9-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-9-trunk/builds/327

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-9-commit' 
triggered this build
Build Source Stamp: [branch 9.0.x] 947ecd09011e6439828b5c2a1890209f94e51438
Blamelist: Mark Thomas 

Build succeeded!

Sincerely,
 -The Buildbot




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

Re: Improving SameSite support

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 10:35, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>  > wrote:
>
>>> Clearly, no, with multiple elements, the digester rules added
>>> to ContextRuleSet would be something like (in addition to the
>>> unchanged ones for CookieProcessor):
>>
>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>
>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>> "Context/CookieProcessor", "setCookieProcessor",
>> "org.apache.tomcat.util.http.CookieProcessor");
>>
>> digester.addObjectCreate(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>>
>>> "org.apache.tomcat.util.http.SameSiteCookie",
>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor/SameSiteCookie");
>> digester.addSetNext(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>> "addSameSiteCookie",
>> "org.apache.tomcat.util.http.SameSiteCookie");
>>
>>> If the bean class is
>>> org.apache.tomcat.util.http.SameSiteCookie.
>
> So you are okay with:
>
> digester.addSetProperties(prefix +
> "Context/CookieProcessor/SameSiteCookie");
>
>
> But not with:
>
> digester.addCallMethod(prefix +
> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
> ?
>
>
> The digester works best with beans so I don't see what is so
> surprising about this.

What's surprising is that you are -1 to what I see as an improvement
to Tomcat without much in the way of disruption. I think it's pretty
clean.

Would proposing an actual patch help, or will you still be -1 on
anything other than a complicated "sameSiteCookies" string value which
needs to be unpacked by Tomcat code rather than using standard XML
element/attribute syntax?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F4eMACgkQHPApP6U8
pFhhkxAAgQdr7vdbaO0qeWHPbKdh2hcy5NuKMOozOWaERHowTsx3yv9rHfiVKaXG
gti6mzcLIqXMPiMbqCE+fYpOCAfqJsAtjjg3zWs9Sh1vk7HOrOmZ7V2s5bbvjeqe
zCcrgdC+PKMO9Up/OWdwfAj8oARhtYFfTQfgoEiT61ElDYNnCU+swuDh9CZwJpv0
HzQ+U+kEEYpgZrawzuk4xCvOSk+HKNAcG5LDphYgLUGUNg3Eq7tlvzDSQ/PX1Hbd
VFHipCk4pDcRgvFq9GYK3b81QAlxcizFOW129+CPRSYINg1ztomv1Gqw+JXiwnG5
YCcd6LaBT0fn3SldtE/rWNZResK3qnQG0aeAFvdl1qzzWvOSMMzyuJB7XMxkRlTZ
lo3w7nJ9dJ4RdtjSshuBj6vrjFxqmAexbhy+e/aWmjKjjuEPl9oZx7jYbGKg79ER
Bn+6nkUEP7YxBMSg9LTqFJvzGw6PPplunn6MTef7PZYpj9qwJh5xg2AXGZqrndmD
XaowT4zNASfguq34BxmACWkqQrc6+3Wvdutafz7yvr0yxrvZz2+pmT6fJ9C6nBQO
4xyqxYRUa+Bt+4b2ppAzrVIJ+egk+6tbcUiqxMvbH1RV7GD+rwyEI5DRtv1RsTiw
lCI9Y4K3R2a1pEN/0nArQrkBAzEttlxTPoZ9eJyUxsuVXtLor6g=
=lUHF
-END PGP SIGNATURE-

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

[Bug 64583] org.apache.tomcat.websocket.pojo.TestEncodingDecoding / testAnnotatedEndPoints - testEvent fails occasionally

[bugzilla]

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

--- Comment #8 from Mark Thomas  ---
Yep. I missed the additional client message. I've updated the test code. It
should pass now.

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

[tomcat] branch 7.0.x updated: Fix failing test

[markt]

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

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


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

commit 4ac8e86347a6a82133354312e7eb8c1aa09bb129
Author: Mark Thomas 
AuthorDate: Wed Jul 8 15:56:06 2020 +0100

Fix failing test
---
 test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
index 93cf639..f929d67 100644
--- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
+++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
@@ -255,7 +255,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 // Should not take very long
 int i = 0;
 while (i < WAIT_LOOPS) {
-if (server.received.size() > 0 && client.received.size() > 0) {
+if (server.received.size() > 0 && client.received.size() > 1) {
 break;
 }
 i++;


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

[markt]

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 947ecd0  Fix failing test
947ecd0 is described below

commit 947ecd09011e6439828b5c2a1890209f94e51438
Author: Mark Thomas 
AuthorDate: Wed Jul 8 15:56:06 2020 +0100

Fix failing test
---
 test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
index 91b9034..f5c5e03 100644
--- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
+++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
@@ -254,7 +254,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 // Should not take very long
 int i = 0;
 while (i < WAIT_LOOPS) {
-if (server.received.size() > 0 && client.received.size() > 0) {
+if (server.received.size() > 0 && client.received.size() > 1) {
 break;
 }
 i++;


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

[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 4183aba  Fix failing test
4183aba is described below

commit 4183aba52d95d3303c4724adb26444cb322897d8
Author: Mark Thomas 
AuthorDate: Wed Jul 8 15:56:06 2020 +0100

Fix failing test
---
 test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
index 91b9034..f5c5e03 100644
--- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
+++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
@@ -254,7 +254,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 // Should not take very long
 int i = 0;
 while (i < WAIT_LOOPS) {
-if (server.received.size() > 0 && client.received.size() > 0) {
+if (server.received.size() > 0 && client.received.size() > 1) {
 break;
 }
 i++;


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

[tomcat] branch master updated: Fix failing test

[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 4b5edd3  Fix failing test
4b5edd3 is described below

commit 4b5edd377e4098fd3f6cc82e87c7b9874f460c07
Author: Mark Thomas 
AuthorDate: Wed Jul 8 15:56:06 2020 +0100

Fix failing test
---
 test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
index ab1d7b1..4b8fb58 100644
--- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
+++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
@@ -254,7 +254,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 // Should not take very long
 int i = 0;
 while (i < WAIT_LOOPS) {
-if (server.received.size() > 0 && client.received.size() > 0) {
+if (server.received.size() > 0 && client.received.size() > 1) {
 break;
 }
 i++;


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

[Bug 64583] org.apache.tomcat.websocket.pojo.TestEncodingDecoding / testAnnotatedEndPoints - testEvent fails occasionally

[bugzilla]

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

--- Comment #7 from Mark Thomas  ---
That looks a lot better.

That new failure is in one of the disabled tests that I enabled. Let me see if
I missed something when I reviewed the test.

-- 
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: Improving SameSite support

[Rémy Maucherat]

On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> >> Clearly, no, with multiple elements, the digester rules added to
> >> ContextRuleSet would be something like (in addition to the
> >> unchanged ones for CookieProcessor):
> >
> > digester.addObjectCreate(prefix + "Context/CookieProcessor",
> >
> >> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
> > "className"); digester.addSetProperties(prefix +
> > "Context/CookieProcessor"); digester.addSetNext(prefix +
> > "Context/CookieProcessor", "setCookieProcessor",
> > "org.apache.tomcat.util.http.CookieProcessor");
> >
> > digester.addObjectCreate(prefix +
> >> "Context/CookieProcessor/SameSiteCookie",
> >
> >> "org.apache.tomcat.util.http.SameSiteCookie",
> > "className"); digester.addSetProperties(prefix +
> >> "Context/CookieProcessor/SameSiteCookie");
> > digester.addSetNext(prefix +
> >> "Context/CookieProcessor/SameSiteCookie",
> > "addSameSiteCookie",
> > "org.apache.tomcat.util.http.SameSiteCookie");
> >
> >> If the bean class is org.apache.tomcat.util.http.SameSiteCookie.
>
> So you are okay with:
>
>   digester.addSetProperties(prefix +
> "Context/CookieProcessor/SameSiteCookie");
>
>
> But not with:
>
>   digester.addCallMethod(prefix +
> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
> ?
>

The digester works best with beans so I don't see what is so surprising
about this.

Rémy


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F150ACgkQHPApP6U8
> pFiyDg//Q/GZr5CpEAtGSpLzDe78kYSDmBrZ3BCif+RBJvOUEarcpBskEDcjo3ux
> uEYUQM4e+AniE3DzdL/3L7AYiaAZc5vwaKF1zE0OkisHJauYybRxPdhr0CwiKQ5R
> /TkPNPc03nwzN/mYvSGUtVo/pyBkJ+2gX8bTFzkBrcha7F+6+lHmGzTpTgKYZVXQ
> +DjmyiHvpSqmrvITYTo4NvNGKMckYzQ1hFXfzlW8fEsJsfxffAZqi3Sz1UikCs8F
> /Tj12b814wNemtMR7nITWObCIGLYt8Xkv+Rv9kbglqsNSmGDv58f8CYGQjk4Mvk7
> JEnLdSexEm979w+QNce3oibTVWdZjab2f1lLotTvcMIMenGHTefmpxlCQCjdMC0l
> WT9EfAJUKC9bUMiysFUgce8DwYFBi9wmkKjBLtl0+Nynyt4GJIMKZlxAocgcEBs6
> BqTa8G8xooC8/x5JSgWEu3r29Zn0zrHE4DJbH4egsoTVH3+U4FjsvMz/4lb/8hK+
> RtRQxNJmPFutw1DEOSxbceahXVpjOXFs8KI09k+uz5OAY1C3alE3h9ig4PzjNzyS
> N9fQ8XlCB+f9Agthjqbc3pNEDP2m2azuex6Wh4k72cyw6IGPreWO4rMTN4sTjGpg
> ibsVK2ZBl7ssxVsgYfAk0r3FV6SAgP6LqhPAYqt1oDPDLcW5f5Y=
> =Q7g+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 64583] org.apache.tomcat.websocket.pojo.TestEncodingDecoding / testAnnotatedEndPoints - testEvent fails occasionally

[bugzilla]

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

--- Comment #6 from Konstantin Kolinko  ---
Created attachment 37354
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37354&action=edit
TEST-org.apache.tomcat.websocket.pojo.TestEncodingDecoding.BIO.txt (7.0.x at
90f95ab8, Java 11)

Testing current 7.0.x (at 90f95ab83874dba5a7062fc0bc8803aecaba1937),
thus far I have 1 failure out of {(20 runs with Java 8 + 20 runs with Java 11)
x 3 connectors}.

I am attaching the log file for the failed test.
The test was with Java 11, BIO connector.

Its a different test method that was failing, so this is really a different
issue.
The failure:
[[[
Testcase: testMessagesEndPoints took 0,08 sec
FAILED
expected:<2> but was:<1>
junit.framework.AssertionFailedError: expected:<2> but was:<1>
at
org.apache.tomcat.websocket.pojo.TestEncodingDecoding.testMessagesEndPoints(TestEncodingDecoding.java:267)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
]]]

-- 
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: Improving SameSite support

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 10:20, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz
>  >
wrote:
>
> Rémy,
>
> On 7/8/20 04:16, Rémy Maucherat wrote:
>> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
>> > 
>>  >> wrote:
>
>> Rémy,
>
>> On 7/7/20 03:10, Rémy Maucherat wrote:
>>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>>> >> 
>>>  >
>>>  
>>  
>>> All,
>
>>> Jakarta EE 5.0 does not appear to include support for SameSite
>>> cookies. Tomcat's CookieProcessor allows an administrator to
>>> set the SameSite cookie policy, but it's a blanket policy.
>
>>> So for example, if you want a JSESSIONID cookie to be "strict"
>>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>>> whatever, you will have to manually-build your "Set-Cookie"
>>> headers for your FOO cooki e.
>
>>> This is not terribly convenient.
>
>>> Unfortunately, *any* solution to this problem will be
>>> container-specific. The current Tomcat solution is of course a
>>> solution only for Tomcat, and only for versions which contain
>>> that SameSite support.
>
>>> I'm wondering if we can do better.
>
>>> Instead of a single "sameSiteCookies" setting which applies to
>>> *all* cookies, perhaps the CookieProcessor could have a
>>> different policy for specific cookies. Something like this:
>
>>> >> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>>> sameSiteCookies="unset"> >> cookieName="JSESSIONID" policy="strict" /> >> cookieName="FOO" policy="lax" /> ... 
>
>>> In the above setup, the "sameSiteCookie" attribute of the
>>> CookieProcessor sets the default policy for the
>>> CookieProcessor. Then, each of the  elements
>>> sets the policy for a specific cookie by name.
>
>>> This would allow applications to set their policies without
>>> having to construct their own Set-Cookie response headers,
>>> handle encoding, etc. and it would also inherit any other
>>> Tomcat-supplied cookie-related policies.
>
>>> Another option would be to provide a subclass of j.s.h.Cookie
>>> which includes a setSameSite(String) method. The
>>> CookieProcessor could check for instanceof EnhancedCookie (or
>>> whatever) and use that setting for each Cookie object. But that
>>> seems like less of a good idea -- except that it would be
>>> easier for refactoring tools to locate instances of the
>>> Tomcat-specific Cookie class and replace them with a future
>>> SameSite-supporting official Jakarta EE Cookie class.
>
>>> WDYT?
>
>
 This is a big configuration and API change. Adding a new
 element is significant, so maybe an expanded syntax could be
 added to the attribute instead (ex:
 "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
 "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a
 breaking change though.
>
>> I think it's *either* an API change *or* a configuration change,
>> not both, and it can be done in a backward compatible way.
>
>> Using a single "complex" configuration value makes it difficult
>> or impossible to write an XML schema for validation. Not
>> critical, but it's a consideration IMHO.
>
>> Nobody HAS to use e.g. a new Cookie class and/or new
>> configuration. My proposed configuration remains
>> backward-compatible because the sameSiteCookies attribute sets
>> the default policy and it's only overridden if you supply some
>> cookie-specific configuration.
>
>> I don't think adding a new XML element as a child of
>> SameSiteCookies is a huge deal: it just requires a bit of
>> Digester configuration and a method to append custom
>> configuration to SameSiteCookies. A quick change to
>> *CookieProcessor.generate() to check for custom settings would be
>> easy, tool. (I'd suggest that the code be refactored so that the
>> SameSiteCookies class returns the proper SameSite cookie
>> attribute (or null/blank) so that each CookieProperssor doesn't
>> have to repeat the logic.)
>
>
>>> If new elements are added, they need to correspond to an
>>> object structure (= there needs to be a SameSiteCookie object
>>> with fields "cookieName" and "policy" being added to a map in
>>> CookieProcessorBase).
>
> The SameSiteCookies class already exists, and it can have a field
> and method added (e.g. addCookie(String cookieName,String policy)).
> The SameSiteCookies object can manage the policies and the
> CookieProcessor classes can delegate the policy decisions to the
> SameSiteCookies object.
>
>>> I am -1 for any custom digester behavior [the Connector
>>> element has this issue, and it's more or less unfixable now

Re: Improving SameSite support

[Rémy Maucherat]

On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rémy,
>
> On 7/8/20 04:16, Rémy Maucherat wrote:
> > On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
> >  > >
> wrote:
> >
> > Rémy,
> >
> > On 7/7/20 03:10, Rémy Maucherat wrote:
> >> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
> >>  >> 
> >>  > >> wrote:
> >
> >> All,
> >
> >> Jakarta EE 5.0 does not appear to include support for SameSite
> >> cookies. Tomcat's CookieProcessor allows an administrator to set
> >> the SameSite cookie policy, but it's a blanket policy.
> >
> >> So for example, if you want a JSESSIONID cookie to be "strict"
> >> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
> >> whatever, you will have to manually-build your "Set-Cookie"
> >> headers for your FOO cooki e.
> >
> >> This is not terribly convenient.
> >
> >> Unfortunately, *any* solution to this problem will be
> >> container-specific. The current Tomcat solution is of course a
> >> solution only for Tomcat, and only for versions which contain
> >> that SameSite support.
> >
> >> I'm wondering if we can do better.
> >
> >> Instead of a single "sameSiteCookies" setting which applies to
> >> *all* cookies, perhaps the CookieProcessor could have a
> >> different policy for specific cookies. Something like this:
> >
> >>  >> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
> >> sameSiteCookies="unset">  >> policy="strict" />  >> /> ... 
> >
> >> In the above setup, the "sameSiteCookie" attribute of the
> >> CookieProcessor sets the default policy for the CookieProcessor.
> >> Then, each of the  elements sets the policy for
> >> a specific cookie by name.
> >
> >> This would allow applications to set their policies without
> >> having to construct their own Set-Cookie response headers,
> >> handle encoding, etc. and it would also inherit any other
> >> Tomcat-supplied cookie-related policies.
> >
> >> Another option would be to provide a subclass of j.s.h.Cookie
> >> which includes a setSameSite(String) method. The CookieProcessor
> >> could check for instanceof EnhancedCookie (or whatever) and use
> >> that setting for each Cookie object. But that seems like less of
> >> a good idea -- except that it would be easier for refactoring
> >> tools to locate instances of the Tomcat-specific Cookie class and
> >> replace them with a future SameSite-supporting official Jakarta
> >> EE Cookie class.
> >
> >> WDYT?
> >
> >
> >>> This is a big configuration and API change. Adding a new
> >>> element is significant, so maybe an expanded syntax could be
> >>> added to the attribute instead (ex:
> >>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
> >>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking
> >>> change though.
> >
> > I think it's *either* an API change *or* a configuration change,
> > not both, and it can be done in a backward compatible way.
> >
> > Using a single "complex" configuration value makes it difficult or
> > impossible to write an XML schema for validation. Not critical,
> > but it's a consideration IMHO.
> >
> > Nobody HAS to use e.g. a new Cookie class and/or new configuration.
> > My proposed configuration remains backward-compatible because the
> > sameSiteCookies attribute sets the default policy and it's only
> > overridden if you supply some cookie-specific configuration.
> >
> > I don't think adding a new XML element as a child of
> > SameSiteCookies is a huge deal: it just requires a bit of Digester
> > configuration and a method to append custom configuration to
> > SameSiteCookies. A quick change to *CookieProcessor.generate() to
> > check for custom settings would be easy, tool. (I'd suggest that
> > the code be refactored so that the SameSiteCookies class returns
> > the proper SameSite cookie attribute (or null/blank) so that each
> > CookieProperssor doesn't have to repeat the logic.)
> >
> >
> >> If new elements are added, they need to correspond to an object
> >> structure (= there needs to be a SameSiteCookie object with
> >> fields "cookieName" and "policy" being added to a map in
> >> CookieProcessorBase).
>
> The SameSiteCookies class already exists, and it can have a field and
> method added (e.g. addCookie(String cookieName,String policy)). The
> SameSiteCookies object can manage the policies and the CookieProcessor
> classes can delegate the policy decisions to the SameSiteCookies object.
>
> >> I am -1 for any custom digester behavior [the Connector element
> >> has this issue, and it's more or less unfixable now], instead the
> >> standard object create, set properties and set next rules have to
> >> be used.
>
> So this isn't okay with you?
>
> digester.addCallMethod(".../Cookie", "addCookie", 2, [String,String]);
> digester.addCallParam("..

Re: [tomcat] branch 7.0.x updated: Bug 64583 - Make tests more robust. Fix disabled tests.

[Mark Thomas]

On 08/07/2020 14:52, kkoli...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> kkolinko pushed a commit to branch 7.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/7.0.x by this push:
>  new 90f95ab  Bug 64583 - Make tests more robust. Fix disabled tests.
> 90f95ab is described below
> 
> commit 90f95ab83874dba5a7062fc0bc8803aecaba1937
> Author: Konstantin Kolinko 
> AuthorDate: Wed Jul 8 16:49:25 2020 +0300
> 
> Bug 64583 - Make tests more robust. Fix disabled tests.
> 
> Followup to previous commit, fixing compilation failures in the test case.
> 
> In build.xml there is no separate compilation step for tests that are 
> running with Java 7 (such as this test).
> All test classes are compiled with -source 1.6 / -target 1.6.

Thanks for fixing this.

Mark


> ---
>  test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
> b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
> index 484a8b4..93cf639 100644
> --- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
> +++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
> @@ -367,7 +367,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
>  @ClientEndpoint
>  public static class StringClient {
>  
> -private final Queue received = new ConcurrentLinkedQueue<>();
> +private final Queue received = new 
> ConcurrentLinkedQueue();
>  
>  @OnMessage
>  public void rx(String in) {
> @@ -398,7 +398,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
>  configurator=SingletonConfigurator.class)
>  public static class MessagesServer {
>  
> -private final Queue received = new ConcurrentLinkedQueue<>();
> +private final Queue received = new 
> ConcurrentLinkedQueue();
>  private volatile Throwable t = null;
>  
>  @OnMessage
> @@ -420,7 +420,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
>  configurator=SingletonConfigurator.class)
>  public static class BatchedServer {
>  
> -private final Queue received = new ConcurrentLinkedQueue<>();
> +private final Queue received = new 
> ConcurrentLinkedQueue();
>  private volatile Throwable t = null;
>  
>  @OnMessage
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

buildbot success in on tomcat-7-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-7-trunk/builds/1735

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf946_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch 7.0.x] 90f95ab83874dba5a7062fc0bc8803aecaba1937
Blamelist: Konstantin Kolinko 

Build succeeded!

Sincerely,
 -The Buildbot




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

Re: Improving SameSite support

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 04:16, Rémy Maucherat wrote:
> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
>  >
wrote:
>
> Rémy,
>
> On 7/7/20 03:10, Rémy Maucherat wrote:
>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>> > 
>>  >> wrote:
>
>> All,
>
>> Jakarta EE 5.0 does not appear to include support for SameSite
>> cookies. Tomcat's CookieProcessor allows an administrator to set
>> the SameSite cookie policy, but it's a blanket policy.
>
>> So for example, if you want a JSESSIONID cookie to be "strict"
>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>> whatever, you will have to manually-build your "Set-Cookie"
>> headers for your FOO cooki e.
>
>> This is not terribly convenient.
>
>> Unfortunately, *any* solution to this problem will be
>> container-specific. The current Tomcat solution is of course a
>> solution only for Tomcat, and only for versions which contain
>> that SameSite support.
>
>> I'm wondering if we can do better.
>
>> Instead of a single "sameSiteCookies" setting which applies to
>> *all* cookies, perhaps the CookieProcessor could have a
>> different policy for specific cookies. Something like this:
>
>> > className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>> sameSiteCookies="unset"> > policy="strict" /> > /> ... 
>
>> In the above setup, the "sameSiteCookie" attribute of the
>> CookieProcessor sets the default policy for the CookieProcessor.
>> Then, each of the  elements sets the policy for
>> a specific cookie by name.
>
>> This would allow applications to set their policies without
>> having to construct their own Set-Cookie response headers,
>> handle encoding, etc. and it would also inherit any other
>> Tomcat-supplied cookie-related policies.
>
>> Another option would be to provide a subclass of j.s.h.Cookie
>> which includes a setSameSite(String) method. The CookieProcessor
>> could check for instanceof EnhancedCookie (or whatever) and use
>> that setting for each Cookie object. But that seems like less of
>> a good idea -- except that it would be easier for refactoring
>> tools to locate instances of the Tomcat-specific Cookie class and
>> replace them with a future SameSite-supporting official Jakarta
>> EE Cookie class.
>
>> WDYT?
>
>
>>> This is a big configuration and API change. Adding a new
>>> element is significant, so maybe an expanded syntax could be
>>> added to the attribute instead (ex:
>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking
>>> change though.
>
> I think it's *either* an API change *or* a configuration change,
> not both, and it can be done in a backward compatible way.
>
> Using a single "complex" configuration value makes it difficult or
> impossible to write an XML schema for validation. Not critical,
> but it's a consideration IMHO.
>
> Nobody HAS to use e.g. a new Cookie class and/or new configuration.
> My proposed configuration remains backward-compatible because the
> sameSiteCookies attribute sets the default policy and it's only
> overridden if you supply some cookie-specific configuration.
>
> I don't think adding a new XML element as a child of
> SameSiteCookies is a huge deal: it just requires a bit of Digester
> configuration and a method to append custom configuration to
> SameSiteCookies. A quick change to *CookieProcessor.generate() to
> check for custom settings would be easy, tool. (I'd suggest that
> the code be refactored so that the SameSiteCookies class returns
> the proper SameSite cookie attribute (or null/blank) so that each
> CookieProperssor doesn't have to repeat the logic.)
>
>
>> If new elements are added, they need to correspond to an object
>> structure (= there needs to be a SameSiteCookie object with
>> fields "cookieName" and "policy" being added to a map in
>> CookieProcessorBase).

The SameSiteCookies class already exists, and it can have a field and
method added (e.g. addCookie(String cookieName,String policy)). The
SameSiteCookies object can manage the policies and the CookieProcessor
classes can delegate the policy decisions to the SameSiteCookies object.

>> I am -1 for any custom digester behavior [the Connector element
>> has this issue, and it's more or less unfixable now], instead the
>> standard object create, set properties and set next rules have to
>> be used.

So this isn't okay with you?

digester.addCallMethod(".../Cookie", "addCookie", 2, [String,String]);
digester.addCallParam(".../Cookie", 0, "cookie");
digester.addCallParam(".../Cookie", 1, "policy");

??

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F1KoACgkQHPApP6U8
pFjLxBAAwQa2RIf7++TEeuX2JSBZBygVATpRJbBQH/s3nI8MsDbG1x8EL6Qcnx/7
cMDztQT63

[tomcat] branch 7.0.x updated: Bug 64583 - Make tests more robust. Fix disabled tests.

[kkolinko]

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

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


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 90f95ab  Bug 64583 - Make tests more robust. Fix disabled tests.
90f95ab is described below

commit 90f95ab83874dba5a7062fc0bc8803aecaba1937
Author: Konstantin Kolinko 
AuthorDate: Wed Jul 8 16:49:25 2020 +0300

Bug 64583 - Make tests more robust. Fix disabled tests.

Followup to previous commit, fixing compilation failures in the test case.

In build.xml there is no separate compilation step for tests that are 
running with Java 7 (such as this test).
All test classes are compiled with -source 1.6 / -target 1.6.
---
 test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java 
b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
index 484a8b4..93cf639 100644
--- a/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
+++ b/test/org/apache/tomcat/websocket/pojo/TestEncodingDecoding.java
@@ -367,7 +367,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 @ClientEndpoint
 public static class StringClient {
 
-private final Queue received = new ConcurrentLinkedQueue<>();
+private final Queue received = new 
ConcurrentLinkedQueue();
 
 @OnMessage
 public void rx(String in) {
@@ -398,7 +398,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 configurator=SingletonConfigurator.class)
 public static class MessagesServer {
 
-private final Queue received = new ConcurrentLinkedQueue<>();
+private final Queue received = new 
ConcurrentLinkedQueue();
 private volatile Throwable t = null;
 
 @OnMessage
@@ -420,7 +420,7 @@ public class TestEncodingDecoding extends TomcatBaseTest {
 configurator=SingletonConfigurator.class)
 public static class BatchedServer {
 
-private final Queue received = new ConcurrentLinkedQueue<>();
+private final Queue received = new 
ConcurrentLinkedQueue();
 private volatile Throwable t = null;
 
 @OnMessage


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

[GitHub] [tomcat] javierlete opened a new pull request #320: Update reqparams.html

[GitBox]

javierlete opened a new pull request #320:
URL: https://github.com/apache/tomcat/pull/320


   Added the request.getParameter that were missing.



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



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

Re: Improving SameSite support

[Rémy Maucherat]

On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Rémy,
>
> On 7/7/20 03:10, Rémy Maucherat wrote:
> > On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
> >  > >
> wrote:
> >
> > All,
> >
> > Jakarta EE 5.0 does not appear to include support for SameSite
> > cookies. Tomcat's CookieProcessor allows an administrator to set
> > the SameSite cookie policy, but it's a blanket policy.
> >
> > So for example, if you want a JSESSIONID cookie to be "strict" but
> > some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever,
> > you will have to manually-build your "Set-Cookie" headers for your
> > FOO cooki e.
> >
> > This is not terribly convenient.
> >
> > Unfortunately, *any* solution to this problem will be
> > container-specific. The current Tomcat solution is of course a
> > solution only for Tomcat, and only for versions which contain that
> > SameSite support.
> >
> > I'm wondering if we can do better.
> >
> > Instead of a single "sameSiteCookies" setting which applies to
> > *all* cookies, perhaps the CookieProcessor could have a different
> > policy for specific cookies. Something like this:
> >
> >  > className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
> > sameSiteCookies="unset">  > policy="strict" />  > /> ... 
> >
> > In the above setup, the "sameSiteCookie" attribute of the
> > CookieProcessor sets the default policy for the CookieProcessor.
> > Then, each of the  elements sets the policy for a
> > specific cookie by name.
> >
> > This would allow applications to set their policies without having
> > to construct their own Set-Cookie response headers, handle
> > encoding, etc. and it would also inherit any other Tomcat-supplied
> > cookie-related policies.
> >
> > Another option would be to provide a subclass of j.s.h.Cookie
> > which includes a setSameSite(String) method. The CookieProcessor
> > could check for instanceof EnhancedCookie (or whatever) and use
> > that setting for each Cookie object. But that seems like less of a
> > good idea -- except that it would be easier for refactoring tools
> > to locate instances of the Tomcat-specific Cookie class and replace
> > them with a future SameSite-supporting official Jakarta EE Cookie
> > class.
> >
> > WDYT?
> >
> >
> >> This is a big configuration and API change. Adding a new element
> >> is significant, so maybe an expanded syntax could be added to the
> >> attribute instead (ex: "unset,JSESSIONID=strict,FOO=lax"; or
> >> maybe a more compact "unset;strict=JSESSIONID,FOO;lax=BAR"). It's
> >> still a breaking change though.
>
> I think it's *either* an API change *or* a configuration change, not
> both, and it can be done in a backward compatible way.
>
> Using a single "complex" configuration value makes it difficult or
> impossible to write an XML schema for validation. Not critical, but
> it's a consideration IMHO.
>
> Nobody HAS to use e.g. a new Cookie class and/or new configuration. My
> proposed configuration remains backward-compatible because the
> sameSiteCookies attribute sets the default policy and it's only
> overridden if you supply some cookie-specific configuration.
>
> I don't think adding a new XML element as a child of SameSiteCookies
> is a huge deal: it just requires a bit of Digester configuration and a
> method to append custom configuration to SameSiteCookies. A quick
> change to *CookieProcessor.generate() to check for custom settings
> would be easy, tool. (I'd suggest that the code be refactored so that
> the SameSiteCookies class returns the proper SameSite cookie attribute
> (or null/blank) so that each CookieProperssor doesn't have to repeat
> the logic.)
>

If new elements are added, they need to correspond to an object structure
(= there needs to be a SameSiteCookie object with fields "cookieName" and
"policy" being added to a map in CookieProcessorBase). I am -1 for any
custom digester behavior [the Connector element has this issue, and it's
more or less unfixable now], instead the standard object create, set
properties and set next rules have to be used.

Rémy


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EhfEACgkQHPApP6U8
> pFhXkxAAje++q65o9aq3L61hG+2y3B8yY+kFdiE+PwyvsVqbikHCSWNCVC3s8bpn
> W56cYtajSGCItQvdrZfi76TowY2tnZHbzcJcquk6WMph/24nVMCekJ66ypQ3T1Hq
> v6sn4sN8PZh8n3KoomeW2vy3oknbh0wX4IoTID333t02X15qdZbkngMmwouodH7d
> aKF0yI2zBasz4J3XmCKWp/w7kfptp7Lf4TmxBcyEFJ1YKgQGMQCvQWUq6nBG9s6x
> lt3fJJxNj44TtLQhu1k7LV/yesVO5V7IDQmvM7QfHo2Ny1M6eeMIMK2Yfelwa0uR
> 3yA5AmcVAVxh2d2PXKDJs1iy6u5hXZJtdXcPwE5qoTA9i4Au8SMDwJZPTmFlwPYc
> NBsJWW4ahXFgcg+TyEZ1qSdk0HOsIrj21gLcsKZ6JMeu0mW2XZ1ekDS49+cBiXon
> IUP7gfvMpGrp1eNbu6qVS6V8Odg1f11+iEC4w7gEhRER3KluHA9ujhMTR3lzR9ns
> FcSmt16S6MNr1PK/5is2pNp4vFeGFVFUxvXxEt4SJGshF+WPrxDnWkCSs/hlRXR9
> 4bhUbXaBQuf827B4rONNepUf+fXo

[tomcat] branch master updated: Push removal to the next major version

[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 0678edb  Push removal to the next major version
0678edb is described below

commit 0678edb189afc5a285d33b3fe033052e6bc31aad
Author: remm 
AuthorDate: Wed Jul 8 10:07:50 2020 +0200

Push removal to the next major version
---
 java/org/apache/coyote/Request.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/java/org/apache/coyote/Request.java 
b/java/org/apache/coyote/Request.java
index dc77bf0..a2af283 100644
--- a/java/org/apache/coyote/Request.java
+++ b/java/org/apache/coyote/Request.java
@@ -571,7 +571,7 @@ public final class Request {
 /**
  *
  * @param startTime time
- * @deprecated This setter will be removed in Tomcat 10.1.
+ * @deprecated This setter will be removed in Tomcat 11
  */
 @Deprecated
 public void setStartTime(long startTime) {


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

[tomcat] branch master updated: Remove deprecated items marked for Tomcat 10 removal

[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 c180b3e  Remove deprecated items marked for Tomcat 10 removal
c180b3e is described below

commit c180b3e160aff5e2374fcf987bac9c0e589b0b94
Author: remm 
AuthorDate: Wed Jul 8 09:57:11 2020 +0200

Remove deprecated items marked for Tomcat 10 removal

Noticed while I was looking at CookieProcessor.
---
 .../apache/tomcat/util/http/CookieProcessor.java   | 25 +--
 .../tomcat/util/http/LegacyCookieProcessor.java|  6 
 .../tomcat/util/http/Rfc6265CookieProcessor.java   |  6 
 .../util/http/TestCookieProcessorGeneration.java   | 36 +++---
 webapps/docs/changelog.xml |  8 +
 5 files changed, 27 insertions(+), 54 deletions(-)

diff --git a/java/org/apache/tomcat/util/http/CookieProcessor.java 
b/java/org/apache/tomcat/util/http/CookieProcessor.java
index c230d4f..6ea0fe9 100644
--- a/java/org/apache/tomcat/util/http/CookieProcessor.java
+++ b/java/org/apache/tomcat/util/http/CookieProcessor.java
@@ -34,21 +34,6 @@ public interface CookieProcessor {
 
 /**
  * Generate the {@code Set-Cookie} HTTP header value for the given Cookie.
- *
- * @param cookie The cookie for which the header will be generated
- *
- * @return The header value in a form that can be added directly to the
- * response
- *
- * @deprecated This method has been replaced with
- * {@link #generateHeader(Cookie, HttpServletRequest)} and will
- * be removed from Tomcat 10 onwards.
- */
-@Deprecated
-String generateHeader(Cookie cookie);
-
-/**
- * Generate the {@code Set-Cookie} HTTP header value for the given Cookie.
  * This method receives as parameter the servlet request so that it can 
make
  * decisions based on request properties. One such use-case is decide if 
the
  * SameSite attribute should be added to the cookie based on the User-Agent
@@ -56,12 +41,6 @@ public interface CookieProcessor {
  * with the SameSite attribute. This is described by https://www.chromium.org/updates/same-site/incompatible-clients";>the
  * Chromium project.
- * 
- * The default implementation calls the deprecated
- * {@link #generateHeader(Cookie)} method. Implementors should not rely on
- * this default method as it is present only for transitional compatibility
- * and will be removed in Tomcat 10 at the same time as the
- * {@link #generateHeader(Cookie)} method.
  *
  * @param request The servlet request
  *
@@ -70,9 +49,7 @@ public interface CookieProcessor {
  * @return The header value in a form that can be added directly to the
  * response
  */
-default String generateHeader(Cookie cookie, HttpServletRequest request) {
-return generateHeader(cookie);
-}
+String generateHeader(Cookie cookie, HttpServletRequest request);
 
 /**
  * Obtain the character set that will be used when converting between bytes
diff --git a/java/org/apache/tomcat/util/http/LegacyCookieProcessor.java 
b/java/org/apache/tomcat/util/http/LegacyCookieProcessor.java
index a3fc73b..9a5078e 100644
--- a/java/org/apache/tomcat/util/http/LegacyCookieProcessor.java
+++ b/java/org/apache/tomcat/util/http/LegacyCookieProcessor.java
@@ -234,12 +234,6 @@ public final class LegacyCookieProcessor extends 
CookieProcessorBase {
 
 
 @Override
-public String generateHeader(Cookie cookie) {
-return generateHeader(cookie, null);
-}
-
-
-@Override
 public String generateHeader(Cookie cookie, HttpServletRequest request) {
 
 /*
diff --git a/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java 
b/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java
index d747880..0864750 100644
--- a/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java
+++ b/java/org/apache/tomcat/util/http/Rfc6265CookieProcessor.java
@@ -100,12 +100,6 @@ public class Rfc6265CookieProcessor extends 
CookieProcessorBase {
 
 
 @Override
-public String generateHeader(jakarta.servlet.http.Cookie cookie) {
-return generateHeader(cookie, null);
-}
-
-
-@Override
 public String generateHeader(jakarta.servlet.http.Cookie cookie, 
HttpServletRequest request) {
 
 // Can't use StringBuilder due to DateFormat
diff --git 
a/test/org/apache/tomcat/util/http/TestCookieProcessorGeneration.java 
b/test/org/apache/tomcat/util/http/TestCookieProcessorGeneration.java
index dfbd794..166be60 100644
--- a/test/org/apache/tomcat/util/http/TestCookieProcessorGeneration.java
+++ b/test/org/apache/tomcat/util/http/TestCookieProcessorGeneration.java
@@ -261,32 +261,32 @@ public class TestCookieProcessorGeneration {
 
 Cookie cookie = new Cook

[tomcat] branch master updated: Push removal to the next major version

[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 f95125c  Push removal to the next major version
f95125c is described below

commit f95125cb2579b23a97472f345030ccf3e0f5776c
Author: remm 
AuthorDate: Wed Jul 8 09:55:50 2020 +0200

Push removal to the next major version
---
 java/org/apache/catalina/realm/GenericPrincipal.java | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java 
b/java/org/apache/catalina/realm/GenericPrincipal.java
index 6d57730..7260da4 100644
--- a/java/org/apache/catalina/realm/GenericPrincipal.java
+++ b/java/org/apache/catalina/realm/GenericPrincipal.java
@@ -68,7 +68,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
Serializable {
  * @param password  Unused
  * @param roles List of roles (must be Strings) possessed by this user
  *
- * @deprecated This method will be removed in Tomcat 10.0.1 onwards
+ * @deprecated This method will be removed in Tomcat 11 onwards
  */
 @Deprecated
 public GenericPrincipal(String name, String password, List roles) {
@@ -99,7 +99,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
Serializable {
  * @param userPrincipal - the principal to be returned from the request
  *getUserPrincipal call if not null; if null, this will be returned
  *
- * @deprecated This method will be removed in Tomcat 10.0.1 onwards
+ * @deprecated This method will be removed in Tomcat 11 onwards
  */
 @Deprecated
 public GenericPrincipal(String name, String password, List roles,
@@ -135,7 +135,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
Serializable {
  * @param loginContext  - If provided, this will be used to log out the 
user
  *at the appropriate time
  *
- * @deprecated This method will be removed in Tomcat 10.0.1 onwards
+ * @deprecated This method will be removed in Tomcat 11 onwards
  */
 @Deprecated
 public GenericPrincipal(String name, String password, List roles,
@@ -187,7 +187,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
Serializable {
  *at the appropriate time
  * @param gssCredential - If provided, the user's delegated credentials
  *
- * @deprecated This method will be removed in Tomcat 10.0.1 onwards
+ * @deprecated This method will be removed in Tomcat 11 onwards
  */
 @Deprecated
 public GenericPrincipal(String name, String password, List roles,


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