[Bug 58813] Incoming requests hang after a website using the ISAPI connector is restarted

[bugzilla]

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

--- Comment #3 from Matthew Reiter  ---
Yes, it is.

-- 
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: [VOTE] Release Apache Tomcat 7.0.71

[Konstantin Kolinko]

2016-09-07 14:00 GMT+03:00 Violeta Georgieva :
> The proposed Apache Tomcat 7.0.71 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.71/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1094/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_71/
>

> The proposed 7.0.71 release is:
> [X] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.71 Stable


1. Good news:


All tests with various java versions (6u45, 7u80, 8u102)  x all
connectors (bio, nio, apr) - OK   Tested with 32-bit JDKs on Windows.
I am ignoring the following failures with 6u45 -
TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.NIO.txt
TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.BIO.txt
TEST-org.apache.catalina.startup.TestHostConfigAutomaticDeployment.APR.txt
TEST-org.apache.tomcat.util.net.TestSsl.APR.txt

TestHostConfigAutomaticDeployment with Java 6u45:
It is known issue with Java 6u45 on Windows caused Java locking jar
(war) files that cannot be renamed. Fixed in Java 7.

TestSsl with Java 6u45:
[[[
Testcase: testSimpleSsl took 4,239 sec
Caused an ERROR
java.lang.RuntimeException: Could not generate DH keypair
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
generate DH keypair
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1222)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)
at 
org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:651)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:625)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:619)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:608)
at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:602)
at org.apache.tomcat.util.net.TestSsl.testSimpleSsl(TestSsl.java:62)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:114)
at 
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
at 
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at 
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215)
Caused by: java.security.InvalidAlgorithmParameterException: Prime
size must be multiple of 64, and can only range from 512 to 1024
(inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at 
java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:107)
]]]

I do not remember seeing it earlier, but as this error is at client
side of a test connection and as the test successfully runs with Java
7 and later I am not very concerned.

The following documentation update in Tomcat 8 explains this "Prime
size must be multiple of 64" issue (see the text added to
ssl-howto.xml).  Maybe add this text to Tomcat 7 documentation as
well?
http://svn.apache.org/viewvc?view=revision=1681703

2. Bad news:
=

Smoke testing fails:

Running with SecurityManager enabled is broken. Jasper fails to
initialize and none of JSP pages work.

I filed the details into Bugzilla:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60101

I think this is a showstopper. That said, this build is usable when
SecurityManager is not enabled.

Best regards,
Konstantin Kolinko

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

[Bug 60101] 7.0.71 (RC): Jasper fails to initialize when running with SecurityManager enabled

[bugzilla]

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

--- Comment #1 from Konstantin Kolinko  ---
Created attachment 34227
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34227=edit
logs.zip - Log files

Log files.

catalina.2016-09-09.log  - Error messages at startup
localhost.2016-09-09.log - Error message when accessing http://localhost:8080/
localhost_access_log.2016-09-09.txt - Shows the only request to
http://localhost:8080/

Some local paths were .

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 60101] New: 7.0.71 (RC): Jasper fails to initialize when running with SecurityManager enabled

[bugzilla]

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

Bug ID: 60101
   Summary: 7.0.71 (RC): Jasper fails to initialize when running
with SecurityManager enabled
   Product: Tomcat 7
   Version: trunk
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: regression
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: knst.koli...@gmail.com

Steps to reproduce:

1. Unzip apache-tomcat-7.0.71.zip
2. set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.8.0_102  (or 6u45 - does not
matter)
3. Start Tomcat with SecurityManager being enabled:
catalina.bat start -security

The following error is observed at startup:

java.lang.ClassNotFoundException:
org.apache.jasper.runtime.JspRuntimeLibrary$PrivilegedIntrospectHelper
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.jasper.security.SecurityClassLoad.securityClassLoad(SecurityClassLoad.java:49)
at
org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:82)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.catalina.core.JasperListener.lifecycleEvent(JasperListener.java:63)
<...>

I'll attach the log file (catalina.2016-09-09.log) with full stacktrace. This
error is reported twice: the first time when it occurs in
SecurityClassLoad.securityClassLoadand() and the second time when it pops up in
JasperListener.lifecycleEvent().

4. Visit http://localhost:8080/

The page fails with Error 500:

java.lang.NoClassDefFoundError: Could not initialize class
org.apache.jasper.compiler.JspRuntimeContext

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

svn commit: r1760110 - /tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java

[violetagg]

Author: violetagg
Date: Fri Sep  9 20:26:11 2016
New Revision: 1760110

URL: http://svn.apache.org/viewvc?rev=1760110=rev
Log:
The comparison should be with the ByteBuffer not with the handler.

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java?rev=1760110=1760109=1760110=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java Fri Sep 
 9 20:26:11 2016
@@ -666,7 +666,7 @@ public class SecureNio2Channel extends N
 getBufHandler()
 
.expand(sslEngine.getSession().getApplicationBufferSize());
 dst = getBufHandler().getReadBuffer();
-} else if(dst == getAppReadBufHandler()) {
+} else if (dst == 
getAppReadBufHandler().getByteBuffer()) {
 getAppReadBufHandler()
 
.expand(sslEngine.getSession().getApplicationBufferSize());
 dst = getAppReadBufHandler().getByteBuffer();



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

svn commit: r1760109 - in /tomcat/trunk/java/org/apache/tomcat/util/net: ApplicationBufferHandler.java AprEndpoint.java Nio2Channel.java Nio2Endpoint.java NioChannel.java NioEndpoint.java SecureNio2Ch

[violetagg]

Author: violetagg
Date: Fri Sep  9 20:18:10 2016
New Revision: 1760109

URL: http://svn.apache.org/viewvc?rev=1760109=rev
Log:
Introducing ApplicationBufferHandler - a callback interface to be able to 
expand the ByteBuffer provided when SocketWrapperBase.read(boolean, 
ByteBuffer). This is a preparation for using the new method 
SocketWrapperBase.read(boolean, ByteBuffer).

Added:
tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java  
 (with props)
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Channel.java
tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapperBase.java

Added: 
tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java?rev=1760109=auto
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java 
(added)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java 
Fri Sep  9 20:18:10 2016
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.util.net;
+
+import java.nio.ByteBuffer;
+
+/**
+ * Callback interface to be able to expand buffers when buffer overflow
+ * exceptions happen
+ */
+public interface ApplicationBufferHandler {
+
+public ByteBuffer getByteBuffer();
+
+public void expand(int size);
+
+}

Propchange: 
tomcat/trunk/java/org/apache/tomcat/util/net/ApplicationBufferHandler.java
--
svn:eol-style = native

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1760109=1760108=1760109=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Fri Sep  9 
20:18:10 2016
@@ -2783,5 +2783,11 @@ public class AprEndpoint extends Abstrac
 SSLSocket.setVerify(socket, SSL.SSL_CVERIFY_REQUIRE, -1);
 SSLSocket.renegotiate(socket);
 }
+
+
+@Override
+public void setAppReadBufHandler(ApplicationBufferHandler handler) {
+// no-op
+}
 }
 }

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Channel.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Channel.java?rev=1760109=1760108=1760109=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Channel.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Channel.java Fri Sep  9 
20:18:10 2016
@@ -213,4 +213,12 @@ public class Nio2Channel implements Asyn
 return DONE;
 }
 
+
+private ApplicationBufferHandler appReadBufHandler;
+public void setAppReadBufHandler(ApplicationBufferHandler handler) {
+this.appReadBufHandler = handler;
+}
+protected ApplicationBufferHandler getAppReadBufHandler() {
+return appReadBufHandler;
+}
 }

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java?rev=1760109=1760108=1760109=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/Nio2Endpoint.java Fri Sep  9 
20:18:10 2016
@@ -1628,6 +1628,12 @@ public class Nio2Endpoint extends Abstra
 

Re: [VOTE] Release Apache Tomcat 7.0.71

[Martin Grigorov]

On Wed, Sep 7, 2016 at 1:00 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.71 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.71/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1094/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_71/
>
> The proposed 7.0.71 release is:
> [ ] Broken - do not release
> [ X ] Stable - go ahead and release as 7.0.71 Stable
>

Tested our main application and Apache Wicket WebSocket integration.


Just one minor thingy:

==> logs/catalina.out <==
Sep 09, 2016 9:59:56 PM org.apache.catalina.core.StandardServer await
WARNING: StandardServer.await: Invalid command '' received

I haven't noticed such log entry before.


>
> Regards,
> Violeta
>

Re: question regarding current versioning scheme

[Mark Thomas]

On 09/09/2016 17:32, Jarosław Górny wrote:
> Hi,
> 
> I need to write a piece of code for the tool I'm working on, to
> compare Tomcat version strings ;) I've been advised on #tomcat channel
> to ask here, so here I am. Please forgive me, but I haven't found
> relevant information on the homepage / docs.
> 
> I see that for 9.x branch there are the builds named 9.0.0.Mx (where x
> are natural numbers starting from 1). I think I haven't seen that
> versioning in previous branches. Should one consider those "M-builds"
> as alpha releases?

Yes. The M is for milestone. The idea, before Oracle stopped work on the
Servlet 4.0 spec and delayed JavaEE 8 indefinitely, was to use
milestones until the spec was final and implemented and then switch to
normal numbering with the usual alpha/beta/stable markers.

Apparently there will be an announcement on JavaEE 8 at JavaOne.
Certainly things are looking up. The Servlet 4.0 spec has starting
moving forward again.

What we end up doing will depend very much on what Oracle say at JavaOne.

> And going further, how beta & RC versions would be called this time? I
> think (at least for 8.x and 7.x) there were no versions like
> "8.0.0-beta", but initial "release" numbers were dubbed as beta (eg.
> 8.0.1, 8.0.2 etc.) Is this going to be maintained?

Yes.

> basically, tl;dr; version:
> are the strings like: "A.B.C.Mx" and "A.B.C" all that I can expect now?

Yes. Probably. Well...

The truthful answer is we don't know. A compelling reason for a new
numbering scheme may come up next week and could we decide to switch.
That is very unlikely but it could happen.

What I can say is that, given how the Tomcat community typically decides
to act, it is extremely unlikely we'd change numbering schemes without a
very, very good reason.

Sorry I can't be absolutely certain but the nature of open source
development based on a meritocracy is that no-one can say for certain
what will or will not happen in the future.

Mark

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

[Bug 60013] Non-ASCII characters in querystring get mangled after URL Rewrite using RewriteValve

[bugzilla]

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

--- Comment #32 from Santhana Preethi  ---
Created attachment 34226
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34226=edit
QueryString Append Failure

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 60013] Non-ASCII characters in querystring get mangled after URL Rewrite using RewriteValve

[bugzilla]

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

--- Comment #31 from Santhana Preethi  ---
There seems to be a double encoding issue in QSA append. I added a test case
with L and QSA flag which failed. 
Looks like the original query string as well as the part of the request URI
which got rewritten as querystring are getting encoded. This needs to be
handled in the isQsappend code block.

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

question regarding current versioning scheme

[Jarosław Górny]

Hi,

I need to write a piece of code for the tool I'm working on, to
compare Tomcat version strings ;) I've been advised on #tomcat channel
to ask here, so here I am. Please forgive me, but I haven't found
relevant information on the homepage / docs.

I see that for 9.x branch there are the builds named 9.0.0.Mx (where x
are natural numbers starting from 1). I think I haven't seen that
versioning in previous branches. Should one consider those "M-builds"
as alpha releases?

And going further, how beta & RC versions would be called this time? I
think (at least for 8.x and 7.x) there were no versions like
"8.0.0-beta", but initial "release" numbers were dubbed as beta (eg.
8.0.1, 8.0.2 etc.) Is this going to be maintained?

basically, tl;dr; version:
are the strings like: "A.B.C.Mx" and "A.B.C" all that I can expect now?

Thanks in advance!

-- 
Jarosław Górny

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

[Bug 60013] Non-ASCII characters in querystring get mangled after URL Rewrite using RewriteValve

[bugzilla]

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

--- Comment #30 from Santhana Preethi  ---
Thanks for the update. The concerns when R flag is used with NE and B flag are
valid. At a glance, the current fix seems to be fine. I will test the latest
changes and get back to you.

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

buildbot failure in on tomcat-trunk

[buildbot]

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

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1760022
Blamelist: markt

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

[Bug 60013] Non-ASCII characters in querystring get mangled after URL Rewrite using RewriteValve

[bugzilla]

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

--- Comment #29 from Mark Thomas  ---
Those most recent tests aren't consistent with httpd's behaviour.

Both Tomcat and httpd process rewrites in very similar ways (to a point).

The original query string is retain in encoded form.
The path URI is processed in decoded and normalized form.
Any query string generated by the rewrite is in decoded form (note this differs
from the original).
Before any rewrite, any decoded elements are encoded.

The NE flag disables the encoding of decoded elements on rewrite.

The B flag encodes back references.

It is therefore possible for unwanted double encoding to occur when B and R are
combined.

It is also possible for UTF-8 bytes to appear directly in the location header
when R is combined with NE.

I'm fairly confident of the latest code but I'll leave it a little while before
back-porting to give you a chance to test it and provide feedback.

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

svn commit: r1760022 - in /tomcat/trunk: java/org/apache/catalina/valves/rewrite/ test/org/apache/catalina/valves/rewrite/

[markt]

Author: markt
Date: Fri Sep  9 13:44:46 2016
New Revision: 1760022

URL: http://svn.apache.org/viewvc?rev=1760022=rev
Log:
Additional review of the fix for bug 60013
After review of the httpd behaviour, update the Rewrite valve to better
align with httpd and modify the existing tests where they do not reflect
current httpd behaviour.
Add additional tests to cover various combinations of R, B, NE and QSA
flags along with UTF-8 values in original URIs, re-written URIs,
original query strings and re-written query strings.

Modified:
tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteRule.java
tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteValve.java
tomcat/trunk/java/org/apache/catalina/valves/rewrite/Substitution.java
tomcat/trunk/test/org/apache/catalina/valves/rewrite/TestRewriteValve.java

Modified: tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteRule.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteRule.java?rev=1760022=1760021=1760022=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteRule.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteRule.java Fri 
Sep  9 13:44:46 2016
@@ -38,7 +38,6 @@ public class RewriteRule {
 substitution.setSub(substitutionString);
 substitution.parse(maps);
 substitution.setEscapeBackReferences(isEscapeBackReferences());
-substitution.setNoEscape(isNoescape());
 }
 // Parse the pattern
 int flags = 0;

Modified: tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteValve.java?rev=1760022=1760021=1760022=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteValve.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/valves/rewrite/RewriteValve.java Fri 
Sep  9 13:44:46 2016
@@ -23,6 +23,7 @@ import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
 import java.io.StringReader;
+import java.net.URLDecoder;
 import java.nio.charset.StandardCharsets;
 import java.util.ArrayList;
 import java.util.Hashtable;
@@ -44,15 +45,54 @@ import org.apache.catalina.Pipeline;
 import org.apache.catalina.connector.Connector;
 import org.apache.catalina.connector.Request;
 import org.apache.catalina.connector.Response;
+import org.apache.catalina.util.URLEncoder;
 import org.apache.catalina.valves.ValveBase;
 import org.apache.tomcat.util.buf.CharChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
-import org.apache.tomcat.util.buf.UDecoder;
 import org.apache.tomcat.util.buf.UriUtil;
 import org.apache.tomcat.util.http.RequestUtil;
 
 public class RewriteValve extends ValveBase {
 
+static URLEncoder ENCODER = new URLEncoder();
+static {
+/*
+ * Replicates httpd's encoding
+ * Primarily aimed at encoding URI paths, so from the spec:
+ *
+ * pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
+ *
+ * unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
+ *
+ * sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
+ *  / "*" / "+" / "," / ";" / "="
+ */
+// ALPHA and DIGIT are always treated as safe characters
+// Add the remaining unreserved characters
+ENCODER.addSafeCharacter('-');
+ENCODER.addSafeCharacter('.');
+ENCODER.addSafeCharacter('_');
+ENCODER.addSafeCharacter('~');
+// Add the sub-delims
+ENCODER.addSafeCharacter('!');
+ENCODER.addSafeCharacter('$');
+ENCODER.addSafeCharacter('&');
+ENCODER.addSafeCharacter('\'');
+ENCODER.addSafeCharacter('(');
+ENCODER.addSafeCharacter(')');
+ENCODER.addSafeCharacter('*');
+ENCODER.addSafeCharacter('+');
+ENCODER.addSafeCharacter(',');
+ENCODER.addSafeCharacter(';');
+ENCODER.addSafeCharacter('=');
+// Add the remaining literals
+ENCODER.addSafeCharacter(':');
+ENCODER.addSafeCharacter('@');
+// Add '/' so it isn't encoded when we encode a path
+ENCODER.addSafeCharacter('/');
+}
+
+
 /**
  * The rewrite rules that the valve will use.
  */
@@ -285,13 +325,13 @@ public class RewriteValve extends ValveB
 // converted to a string
 MessageBytes urlMB = context ? request.getRequestPathMB() : 
request.getDecodedRequestURIMB();
 urlMB.toChars();
-CharSequence url = urlMB.getCharChunk();
+CharSequence urlDecoded = urlMB.getCharChunk();
 CharSequence host = request.getServerName();
 boolean rewritten = false;
 boolean 

svn commit: r1760006 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/tomcat/util/net/SecureNio2Channel.java java/org/apache/tomcat/util/net/SecureNioChannel.java

[violetagg]

Author: violetagg
Date: Fri Sep  9 13:07:53 2016
New Revision: 1760006

URL: http://svn.apache.org/viewvc?rev=1760006=rev
Log:
Access the socket buffer handler via getBufHandler method for consistency with 
the rest of the code.

Modified:
tomcat/tc8.5.x/trunk/   (props changed)
tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java

Propchange: tomcat/tc8.5.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Fri Sep  9 13:07:53 2016
@@ -1 +1 @@
-/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409,1741501
 
,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747404,1747506,1747536,1747
 
924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1756289,1756408-1756410,1
 
756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757853,1757903,1757997,1758072-1758075,1758078-1758079,1758292,1758369,1758423,1758425-1758427,1758430,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759611

svn commit: r1760005 - in /tomcat/trunk/java/org/apache/tomcat/util/net: SecureNio2Channel.java SecureNioChannel.java

[violetagg]

Author: violetagg
Date: Fri Sep  9 12:59:02 2016
New Revision: 1760005

URL: http://svn.apache.org/viewvc?rev=1760005=rev
Log:
Access the socket buffer handler via getBufHandler method for consistency with 
the rest of the code.

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java?rev=1760005=1760004=1760005=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/SecureNio2Channel.java Fri Sep 
 9 12:59:02 2016
@@ -378,7 +378,7 @@ public class SecureNio2Channel extends N
 
 // Ensure the application buffers (which have to be created earlier) 
are
 // big enough.
-bufHandler.expand(sslEngine.getSession().getApplicationBufferSize());
+
getBufHandler().expand(sslEngine.getSession().getApplicationBufferSize());
 if (netOutBuffer.capacity() < 
sslEngine.getSession().getApplicationBufferSize()) {
 // Info for now as we may need to increase DEFAULT_NET_BUFFER_SIZE
 log.info(sm.getString("channel.nio.ssl.expandNetOutBuffer",
@@ -465,8 +465,8 @@ public class SecureNio2Channel extends N
 //so we can clear it here.
 netOutBuffer.clear();
 //perform the wrap
-bufHandler.configureWriteBufferForRead();
-SSLEngineResult result = sslEngine.wrap(bufHandler.getWriteBuffer(), 
netOutBuffer);
+getBufHandler().configureWriteBufferForRead();
+SSLEngineResult result = 
sslEngine.wrap(getBufHandler().getWriteBuffer(), netOutBuffer);
 //prepare the results to be written
 netOutBuffer.flip();
 //set the status
@@ -491,8 +491,8 @@ public class SecureNio2Channel extends N
 //prepare the buffer with the incoming data
 netInBuffer.flip();
 //call unwrap
-bufHandler.configureReadBufferForWrite();
-result = sslEngine.unwrap(netInBuffer, bufHandler.getReadBuffer());
+getBufHandler().configureReadBufferForWrite();
+result = sslEngine.unwrap(netInBuffer, 
getBufHandler().getReadBuffer());
 //compact the buffer, this is an optional method, wonder what 
would happen if we didn't
 netInBuffer.compact();
 //read in the status
@@ -661,11 +661,11 @@ public class SecureNio2Channel extends N
 } else {
 // The SSL session has increased the required buffer 
size
 // since the buffer was created.
-if (dst == 
socket.getSocketBufferHandler().getReadBuffer()) {
+if (dst == getBufHandler().getReadBuffer()) {
 // This is the normal case for this code
-socket.getSocketBufferHandler().expand(
-
sslEngine.getSession().getApplicationBufferSize());
-dst = 
socket.getSocketBufferHandler().getReadBuffer();
+getBufHandler()
+
.expand(sslEngine.getSession().getApplicationBufferSize());
+dst = getBufHandler().getReadBuffer();
 } else {
 // Can't expand the buffer as there is no way to 
signal
 // to the caller that the buffer has been replaced.
@@ -846,11 +846,11 @@ public class SecureNio2Channel extends N
 } else {
 // The SSL session has increased the 
required buffer size
 // since the buffer was created.
-if (dst2 == 
socket.getSocketBufferHandler().getReadBuffer()) {
+if (dst2 == 
getBufHandler().getReadBuffer()) {
 // This is the normal case for this 
code
-socket.getSocketBufferHandler().expand(
+getBufHandler().expand(
 
sslEngine.getSession().getApplicationBufferSize());
-dst2 = 
socket.getSocketBufferHandler().getReadBuffer();
+dst2 = getBufHandler().getReadBuffer();
 } else {
 // Can't expand the buffer as there is 
no way to signal
 // to the caller that the buffer has 
been replaced.

Modified: 

[Bug 60076] ClientAbortException / IOException occurs only when using HttpServletResponseWrapper

[bugzilla]

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

Olivier Jaquemet  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Olivier Jaquemet  ---
OKay, everything is now much clearer to me.

Thank you Mark for the taking the time to analyze this issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 60100] New: Garbage appended at end of request URL

[bugzilla]

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

Bug ID: 60100
   Summary: Garbage appended at end of request URL
   Product: Tomcat 8
   Version: 8.0.32
  Hardware: Other
OS: AIX
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket
  Assignee: dev@tomcat.apache.org
  Reporter: giovacchini.and...@konvergence.it

After some months of normal work one of our servlets started giving null
pointer exception due to the received requests, so we thought the problem was
the calling application, but when we debugged it we saw it was doing good
requests so last resort was to restart Tomcat then everything worked fine.

These are the details from localhost_access_log:


Bad requests had all these "%20HTTP/1.1%22%20200%20111" in the end:

10.160.252.23 - - [09/Sep/2016:11:26:44 +0200] "GET
/EkoLoyServlet/EkoLoyServlet?codiceCarta=08882401=vs5=true=001=ISO-8859-1=false=true=true=true=true%20HTTP/1.1%22%20200%20111
HTTP/1.1" 200 2842


Good request are like these:

10.160.252.24 - - [09/Sep/2016:11:29:30 +0200] "GET
/EkoLoyServlet/EkoLoyServlet?codiceCarta=08882401=vs5=true=001=ISO-8859-1=false=true=true=true=true
HTTP/1.1" 200 111


Tomcat version is 8.0.32, I've searched the change notes for 8.0.x version
released after our and I've not recognized problems like these.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 58813] Incoming requests hang after a website using the ISAPI connector is restarted

[bugzilla]

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

--- Comment #2 from Christian Swoboda  ---
Hi!

I added your patch description to the following silimar bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=59334

It seems to be the same bug.

Here (again) the details of what should be done:

TerminateFilter (in jk_isapi_plugin.c) 

version 1.2.41 
Line 2424:ReleaseMutex(_cs);

should be:ReleaseMutex(init_cs);


That's the patch you have tested successfully, right?

kind regards
   swobi

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 59334] .NET Application Pools requests hang because Jakarta/Tomcat uses a Named Mutex that is currently owned by a different process

[bugzilla]

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

--- Comment #8 from Christian Swoboda  ---
Hi!

I think the link to the proposed patch should be to:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58813#c1

Matthew Reiter analyzed the problem there in detail and found out that the bug
is in TerminateFilter (in jk_isapi_plugin.c) 

version 1.2.41 
Line 2424:ReleaseMutex(_cs);

should be:ReleaseMutex(init_cs);

Here is his explanation:
---
In TerminateFilter (in jk_isapi_plugin.c), ReleaseMutex is being called with
the address of the init_cs variable rather than its value, causing init_cs to
never be released. As a result, when GetExtensionVersion is subsequently
called, it is unable to acquire init_cs and so the plugin never finishes
initializing. I was able to confirm that removing the extra "&" fixes the
problem.
---

Could you please fix this, cause we are having this critical problem as well!

Thanks!
  swobi

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