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 a
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
Mark Thomas changed:
What|Removed |Added
Resolution|LATER |WONTFIX
--- Comment #10 from Mark Th
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
ste...@navolutions.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
ste...@navolutions.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolutio
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 hen
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. htt
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
Konstantin Kolinko changed:
What|Removed |Added
CC||rajat@gmail.com
--- Comme
https://issues.apache.org/bugzilla/show_bug.cgi?id=46802
Konstantin Kolinko changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from
https://issues.apache.org/bugzilla/show_bug.cgi?id=49198
Konstantin Kolinko changed:
What|Removed |Added
CC||ste...@navolutions.com
--- Co
https://issues.apache.org/bugzilla/show_bug.cgi?id=50832
Konstantin Kolinko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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.
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
> g
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831
Konstantin Kolinko changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
As
https://issues.apache.org/bugzilla/show_bug.cgi?id=50831
Marc Batchelor changed:
What|Removed |Added
OS/Version||All
--- Comment #1 from Marc Batc
https://issues.apache.org/bugzilla/show_bug.cgi?id=49284
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Author: markt
Date: Fri Feb 25 19:19:13 2011
New Revision: 1074675
URL: http://svn.apache.org/viewvc?rev=1074675&view=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 rea
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
Author: markt
Date: Fri Feb 25 15:58:08 2011
New Revision: 1074597
URL: http://svn.apache.org/viewvc?rev=1074597&view=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
2011/2/25 Mark Thomas :
> 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
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
22 matches
Mail list logo
