Response.getWriter(), getOutputStream(), setContentLength() spec issues
The changes [1] for bug 50748 [2] (be aware the bug number changed) have triggered some Servlet 3.0 TCK failures. I don't want to get into the details of those tests, but I do want to discuss the root cause. Consider the following scenario: Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes In this case everything works as expected. Now add a filter to the mix that adds additional content to the response Filter calls getOutputStream() or getWriter() Filter writes 20 bytes to the response Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes There are a couple of potential issues in the second scenario: - If the Filter called getOutputStream(), the Servlet must also call getOutputStream() - If the Filter called getWriter(), the Servlet must also call getWriter() - The response contains 120 bytes but the content length header says 100 so the response is truncated by 20 bytes. This final point is (essentially) what is causing the TCK failures. The Servlet in question is the default Servlet. Prior to the commit for bug 50748, scenario 2 above would have worked if getWriter() had been used but would have failed if getOutputStream() has been used. One of the things I like about the fix for bug 50748 is that the behaviour is now consistent regardless of whether getOutputStream() or getWriter() is called. I couldn't find much in the spec about what is correct in this case although the spec does seem to imply that if a filter is going to modify the response, it should wrap the response. So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. 2. Should Tomcat try and handle this situation (e.g. if any bytes have been written by a filter, commit the response). This could be tricky to get right when forwards are involved and the response is meant to have been cleared. I'm leaning towards not doing this. 3. Is any filter that writes to the response without wrapping it so any calls to setContentLength() can be intercepted and adjusted as necessary broken? I think it is. Thoughts? I'd like to reach some conclusions fairly speedily as this might hold up a 7.0.9 release. If we conclude that the filter is at fault in point 3, we'll need to raise a TCK challenge. Mark [1] http://svn.apache.org/viewvc?rev=1069131view=rev [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=50748 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Response.getWriter(), getOutputStream(), setContentLength() spec issues
2011/2/25 Mark Thomas ma...@apache.org: The changes [1] for bug 50748 [2] (be aware the bug number changed) have triggered some Servlet 3.0 TCK failures. I don't want to get into the details of those tests, but I do want to discuss the root cause. Consider the following scenario: Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes In this case everything works as expected. Now add a filter to the mix that adds additional content to the response Filter calls getOutputStream() or getWriter() Filter writes 20 bytes to the response Servlet knows it will return exactly 100 bytes of content Servlet calls setContentLength() Servlet calls getOutputStream() or getWriter() Servlet writes 100 bytes (...) The Servlet in question is the default Servlet. (..) So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. +1 2. Should Tomcat try and handle this situation (e.g. if any bytes have been written by a filter, commit the response). -1. The filter could call flush() by itself. Though I think relying on flush() so that setContentLength were ignored is a weak workaround. 3. Is any filter that writes to the response without wrapping it so any calls to setContentLength() can be intercepted and adjusted as necessary broken? I think it is. I think that any filter that prepends or appends data to a static file (e.g. to add a license, an add, a message -- there are certainly are sites that append their adds) must either a) take care of - setContentLength(), - setHeader(content-length), setIntHeader(content-length) calls b) use context.getRequestDispatcher(...).include(..) I agree that if the filter does not do either a) or b) then the filter is broken. I have not checked yet whet HTTP spec says about content-length header by cllients. I wonder what happens when content generation with a content-length header fails in the middle. (and e.g. the ErrorReportValve appends additional content).The enforcement of the response length I think is there because otherwise it can break clients (or proxies) and thus is legit. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1074597 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Author: markt
Date: Fri Feb 25 15:58:08 2011
New Revision: 1074597
URL: http://svn.apache.org/viewvc?rev=1074597view=rev
Log:
Avoid NPEs trying to re-negotiate with NIO
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java?rev=1074597r1=1074596r2=1074597view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java Fri Feb
25 15:58:08 2011
@@ -143,7 +143,7 @@ class JSSESupport implements SSLSupport,
}
if (jsseCerts == null)
jsseCerts = new X509Certificate[0];
-if(jsseCerts.length = 0 force) {
+if(jsseCerts.length = 0 force ssl != null) {
session.invalidate();
handShake();
session = ssl.getSession();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50831] New: j_security_check handling doesn't handle original request anchors
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831 Summary: j_security_check handling doesn't handle original request anchors Product: Tomcat 6 Version: 6.0.29 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Servlet JSP API AssignedTo: dev@tomcat.apache.org ReportedBy: mbatche...@pentaho.com Created an attachment (id=26694) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26694) Replacement for jsp/security/protected/index.jsp When linking to a protected resource with anchor specified in the URL using Form Authentication, tomcat directs to the login page (correct) and upon successful authentication, directs to the original request but strips off the anchor. Example: 1- Copy altered attached index.jsp into examples/jsp/security/protected (replace index.jsp). 2- Link to the JSP with an anchor: http://localhost/examples/jsp/security/protected/index.jsp#sectc 3- Note you will be correctly linked to the login JSP. Authenticate with both/tomcat. 4- Upon successful authentication, you are directed to the index page, but it doesn't follow the anchor. Look at the URL in the address bar and you'll see that the anchor was stripped off by Tomcat. 5- Re-paste the original URL from #2 above, and notice that the anchor is valid and works. Tested in Tomcat 5.5.29 and 6.0.29. Tested with Chrome and Firefox. The attached index.jsp has three different anchor points and long sections of junk between them so you can easily see when the page retains the anchor and when it doesn't. Since Tomcat handles all the j_security_check stuff internally, I can't find a work-around that will let me get the original requested URL with the anchor. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
Author: markt
Date: Fri Feb 25 19:19:13 2011
New Revision: 1074675
URL: http://svn.apache.org/viewvc?rev=1074675view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49284
Support SSL re-negotiation in the HTTP NIO connector
There is a fair amount of renaming in this patch. The real work is in the new
rehandshake() method in the SecureNioChannel.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Feb
25 19:19:13 2011
@@ -23,6 +23,8 @@ import java.nio.channels.SelectionKey;
import java.util.Locale;
import java.util.concurrent.Executor;
+import javax.net.ssl.SSLEngine;
+
import org.apache.coyote.ActionCode;
import org.apache.coyote.Request;
import org.apache.coyote.RequestInfo;
@@ -42,7 +44,9 @@ import org.apache.tomcat.util.net.NioCha
import org.apache.tomcat.util.net.NioEndpoint;
import org.apache.tomcat.util.net.NioEndpoint.KeyAttachment;
import org.apache.tomcat.util.net.SSLSupport;
+import org.apache.tomcat.util.net.SecureNioChannel;
import org.apache.tomcat.util.net.SocketStatus;
+import org.apache.tomcat.util.net.jsse.JSSEFactory;
/**
@@ -625,8 +629,25 @@ public class Http11NioProcessor extends
.setLimit(maxSavePostSize);
inputBuffer.addActiveFilter
(inputFilters[Constants.BUFFERED_FILTER]);
+
+SecureNioChannel sslChannel = (SecureNioChannel) socket;
+SSLEngine engine = sslChannel.getSslEngine();
+if (!engine.getNeedClientAuth()
!engine.getWantClientAuth()) {
+// Need to re-negotiate SSL connection
+engine.setNeedClientAuth(true);
+try {
+sslChannel.rehandshake();
+sslSupport = (new JSSEFactory()).getSSLSupport(
+engine.getSession());
+} catch (IOException ioe) {
+
log.warn(sm.getString(http11processor.socket.sslreneg,
+ioe));
+}
+}
try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
+// use force=false since re-negotiation is handled above
+// (and it is a NO-OP for NIO anyway)
+Object sslO = sslSupport.getPeerCertificateChain(false);
if( sslO != null) {
request.setAttribute
(SSLSupport.CERTIFICATE_KEY, sslO);
Modified: tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties Fri Feb
25 19:19:13 2011
@@ -31,6 +31,7 @@ http11processor.request.process=Error pr
http11processor.request.finish=Error finishing request
http11processor.response.finish=Error finishing response
http11processor.socket.info=Exception getting socket information
+http11processor.socket.sslreneg=Exception re-negotiating SSL connection
http11processor.socket.ssl=Exception getting SSL attributes
http11processor.socket.timeout=Error setting socket timeout
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java Fri Feb 25
19:19:13 2011
@@ -175,7 +175,7 @@ public class NioChannel implements ByteC
* @return boolean
* TODO Implement this org.apache.tomcat.util.net.SecureNioChannel method
*/
-public boolean isInitHandshakeComplete() {
+public boolean isHandshakeComplete() {
return true;
}
Modified:
DO NOT REPLY [Bug 49284] Implement SSL renegotiation for the NIO connector
https://issues.apache.org/bugzilla/show_bug.cgi?id=49284 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2011-02-25 14:19:13 EST --- Fixed in 7.0.x and will be included in 7.0.9 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50831] j_security_check handling doesn't handle original request anchors
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831 Marc Batchelor mbatche...@pentaho.com changed: What|Removed |Added OS/Version||All --- Comment #1 from Marc Batchelor mbatche...@pentaho.com 2011-02-25 14:21:31 EST --- Further looking with tracing tools indicates that the anchor is never actually sent to the server. So there's no way for the server (Tomcat) to store it in the SavedRequest object without it being sent to the server. There really isn't a work-around that I can see at this point. Since the server processes the j_security_check, and the redirect rightly goes to the login page, by the time it lands there, the anchor bit is completely lost. Given all this, it's safe to close this. My only recourse in my current application is to rewrite handling to not use anchors. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50832] New: Missing mod_jk x64
https://issues.apache.org/bugzilla/show_bug.cgi?id=50832 Summary: Missing mod_jk x64 Product: Tomcat 7 Version: unspecified Platform: PC Status: NEW Severity: critical Priority: P2 Component: Integration AssignedTo: dev@tomcat.apache.org ReportedBy: ste...@navolutions.com So I wouldn't put it as critical, but someone already reported it back in 2009, 2009 COMMON! The .so is not in the http://mirror.its.uidaho.edu/pub/apache//tomcat/tomcat-connectors/jk/binaries/win64/. The bug that was on before was Status: RESOLVED INVALID... really? Then where is it? The bug was https://issues.apache.org/bugzilla/show_bug.cgi?id=46802. And the 3rd comment was just silly, Bugzilla is not a support forum. Please proceed this discussion on the users list. The originating user was not making a discussion out of his comment he was further defining the BUG. So let me redefine it all the .so file required to install mod_jk into wamp is missing for x64 computers. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50831] j_security_check handling doesn't handle original request anchors
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-25 14:30:07 EST --- Further looking with tracing tools indicates that the anchor is never actually sent to the server. Yes, this is how it works. It has nothing to do with Tomcat. Thus I am closing this as INVALID. Just a note: Servlet 3.0 spec (implemented by Tomcat 7.0.+) allows to perform login() programmatically. Maybe that will help you. Also using BASIC or DIGEST auth methods won't suffer from this issue. If you want to discuss this further, please use the users@ mailing list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Response.getWriter(), getOutputStream(), setContentLength() spec issues
Mark, On 2/25/2011 7:01 AM, Mark Thomas wrote: So, the questions we need to decide: 1. Is the fix for bug 50748 correct? I think it is. +0 2. Should Tomcat try and handle this situation (e.g. if any bytes have been written by a filter, commit the response). This could be tricky to get right when forwards are involved and the response is meant to have been cleared. I'm leaning towards not doing this. The Filter definitely needs to be able to set headers and append content to the response entity. I'm not sure about a Filter having a legitimate reason to write content /before/ the servlet does to the response entity... I'm having trouble thinking of a use case for that. Given that, having the Filter write anything to the response stream/writer seems reasonable to commit the response. On the other hand, why should a filter act any differently than a servlet? What I mean is that the response won't be committed when a servlet writes to the response until the response buffer has been filled, or an explicit flush() has been called. Also, a servlet should have the opportunity to reset the response if possible given the commit state. I think that makes me -1 on this one. 3. Is any filter that writes to the response without wrapping it so any calls to setContentLength() can be intercepted and adjusted as necessary broken? I think it is. +1 Where does this fail the TCK? Do we have a broken Filter, or does the TCK test an unusual/stupid scenario? Thoughts? I'd like to reach some conclusions fairly speedily as this might hold up a 7.0.9 release. If we conclude that the filter is at fault in point 3, we'll need to raise a TCK challenge. I guess that answers my question. We could have a just-pass-the-damned-TCK configuration flag (or maybe something less inflammatory) that would change this behavior to commit-on-write for Filters. -chris signature.asc Description: OpenPGP digital signature
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
This looks like a CPU spinning handshake to me.
The operation handshake(true, true); returns an IO interest to be
registered with a selector.
If the client is slow here or misbehaving, you could end up in a end
less loop, and hence we can have introduced a very simple DoS
vulnerability here.
The simplest solution is, would be to use an individual selector.
Register the socket and issue a select() on the thread you are running on.
If you want to use a shared selector (like NIO does for reads and
writes) it requires a bit more logic.
I understand where you are going with this solution, and I can probably
fix this today as I sit on the airplane on my way home.
best
Filip
On 02/25/2011 12:19 PM, ma...@apache.org wrote:
Author: markt
Date: Fri Feb 25 19:19:13 2011
New Revision: 1074675
URL: http://svn.apache.org/viewvc?rev=1074675view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49284
Support SSL re-negotiation in the HTTP NIO connector
There is a fair amount of renaming in this patch. The real work is in the new
rehandshake() method in the SecureNioChannel.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Feb
25 19:19:13 2011
@@ -23,6 +23,8 @@ import java.nio.channels.SelectionKey;
import java.util.Locale;
import java.util.concurrent.Executor;
+import javax.net.ssl.SSLEngine;
+
import org.apache.coyote.ActionCode;
import org.apache.coyote.Request;
import org.apache.coyote.RequestInfo;
@@ -42,7 +44,9 @@ import org.apache.tomcat.util.net.NioCha
import org.apache.tomcat.util.net.NioEndpoint;
import org.apache.tomcat.util.net.NioEndpoint.KeyAttachment;
import org.apache.tomcat.util.net.SSLSupport;
+import org.apache.tomcat.util.net.SecureNioChannel;
import org.apache.tomcat.util.net.SocketStatus;
+import org.apache.tomcat.util.net.jsse.JSSEFactory;
/**
@@ -625,8 +629,25 @@ public class Http11NioProcessor extends
.setLimit(maxSavePostSize);
inputBuffer.addActiveFilter
(inputFilters[Constants.BUFFERED_FILTER]);
+
+SecureNioChannel sslChannel = (SecureNioChannel) socket;
+SSLEngine engine = sslChannel.getSslEngine();
+if (!engine.getNeedClientAuth()
!engine.getWantClientAuth()) {
+// Need to re-negotiate SSL connection
+engine.setNeedClientAuth(true);
+try {
+sslChannel.rehandshake();
+sslSupport = (new JSSEFactory()).getSSLSupport(
+engine.getSession());
+} catch (IOException ioe) {
+
log.warn(sm.getString(http11processor.socket.sslreneg,
+ioe));
+}
+}
try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
+// use force=false since re-negotiation is handled above
+// (and it is a NO-OP for NIO anyway)
+Object sslO = sslSupport.getPeerCertificateChain(false);
if( sslO != null) {
request.setAttribute
(SSLSupport.CERTIFICATE_KEY, sslO);
Modified: tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties Fri Feb
25 19:19:13 2011
@@ -31,6 +31,7 @@ http11processor.request.process=Error pr
http11processor.request.finish=Error finishing request
http11processor.response.finish=Error finishing response
http11processor.socket.info=Exception getting socket information
+http11processor.socket.sslreneg=Exception re-negotiating SSL connection
http11processor.socket.ssl=Exception getting SSL attributes
http11processor.socket.timeout=Error setting socket timeout
Modified:
DO NOT REPLY [Bug 50832] Missing mod_jk x64
https://issues.apache.org/bugzilla/show_bug.cgi?id=50832 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE OS/Version||All --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-25 15:16:39 EST --- The ASF policy is to provide source code. There is no guarantee that the binaries will ever be provided (though some projects provide them). Given that there are no official 64-bit Windows binaries of Apache HTTPD, chances for 64-bit mod_jk binary are not so high. https://issues.apache.org/bugzilla/show_bug.cgi?id=49198#c4 If you want to discuss this, please use the users@ mailing list. As you already know, bugzilla is not a support forum. *** This bug has been marked as a duplicate of bug 49198 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added CC||ste...@navolutions.com --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-25 15:16:42 EST --- *** Bug 50832 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46802] Unable to locate mod_jk for 64-bit machine
https://issues.apache.org/bugzilla/show_bug.cgi?id=46802 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-25 15:18:02 EST --- Marking as duplicate. *** This bug has been marked as a duplicate of bug 49198 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added CC||rajat@gmail.com --- Comment #6 from Konstantin Kolinko knst.koli...@gmail.com 2011-02-25 15:18:02 EST --- *** Bug 46802 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 --- Comment #7 from ste...@navolutions.com 2011-02-25 15:26:49 EST --- http://www.wampserver.com/en/download.php has a x64 binary. So yes there is a point and there is someone else who already builds so it is not something that wont fix. http://www.blackdot.be/, this has been an issue since 2009 COMMON just fix it. 3 years is a major cop out x64 it the future, to say things like No point providing 64-bit mod_jk while there is no matching httpd 64-bit binary for Windows. is extremely naive! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
On 25/02/2011 20:16, Filip Hanik - Dev Lists wrote: This looks like a CPU spinning handshake to me. Opps. The operation handshake(true, true); returns an IO interest to be registered with a selector. If the client is slow here or misbehaving, you could end up in a end less loop, and hence we can have introduced a very simple DoS vulnerability here. The simplest solution is, would be to use an individual selector. Register the socket and issue a select() on the thread you are running on. If you want to use a shared selector (like NIO does for reads and writes) it requires a bit more logic. I understand where you are going with this solution, and I can probably fix this today as I sit on the airplane on my way home. If you could, that would be great. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 ste...@navolutions.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #8 from ste...@navolutions.com 2011-02-25 15:28:16 EST --- FIX IT -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 ste...@navolutions.com changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|INVALID |LATER --- Comment #9 from ste...@navolutions.com 2011-02-25 15:49:41 EST --- Probably a lot of things you just try and sweet under the rug, this is why I hate open source crap, and I am sure it is why a lot of people do! People like you are the ones preventing the open source community from growing. Close minded and set it your ways. You could just make it as an open bug to fix later, but no mark it as INVALID and RESOLVED! IT WAS NOT RESOLVED! That is why I left the PHP community, bunch of stupid close minded programmers. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49198] There are no binaries for mod_jk for 64bit?
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198 Mark Thomas ma...@apache.org changed: What|Removed |Added Resolution|LATER |WONTFIX --- Comment #10 from Mark Thomas ma...@apache.org 2011-02-25 16:02:52 EST --- This is not going to be fixed. 1. The ASF does not provide a 64-bit Windows build for httpd so there is little point in the ASF providing a 64-bit mod_jk build. 2. The ASF provides *source code* for its users. Binaries are *sometimes* provided as a *convenience* for users. Not all projects provide binaries and those that do, do not always provide them for all platforms. If users want binaries for a platform that is not available from the ASF they are expected to build it themselves from source. Assistance with building from source is always available from the users list although you may want to adjust your tone if you want someone there to actually help you. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Response.getWriter(), getOutputStream(), setContentLength() spec issues
On 25/02/2011 19:38, Christopher Schultz wrote: Where does this fail the TCK? Do we have a broken Filter, or does the TCK test an unusual/stupid scenario? I am afraid I can't be more specific about this, the TCK is protected by an NDA. For that reason, I deliberately simplified my example to address the root cause rather than what the TCK is actually testing. Specific TCK discussions are held on the private mailing list. BTW, as a committer if you want access to the TCK, you just need to sign and submit the NDA. Thoughts? I'd like to reach some conclusions fairly speedily as this might hold up a 7.0.9 release. If we conclude that the filter is at fault in point 3, we'll need to raise a TCK challenge. I guess that answers my question. We could have a just-pass-the-damned-TCK configuration flag (or maybe something less inflammatory) that would change this behavior to commit-on-write for Filters. We could, but if the consensus is that the TCK is wrong (and so far it seems to be ) I'd be happy releasing Tomcat with a we pass the TCK apart from an undisclosed number of tests we are currently challenging. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
