Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in
On Tue, 2007-06-12 at 19:50 +0200, Mladen Turk wrote: Jean-Frederic wrote: Add ForwardURIProxy to the URl handling option. common/jk_url.c is just a porting of the routines from proxy_util.c (Apache httpd). After quite a few discussions, I think this should be the only mode available for URI handling, as the two others are broken. Comments ? Additionaly I want to rollback r544137 too. Why? To reach the following: url file/dir TC Compat Proxy Proxy-r544137 %252007%2007 ok no okok %252E%252E %2E%2E ok no nook Of course using Compat-r544137 would reopen the vulnerability. Cheers Jean-Frederic Let's stop a bit and test things before. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42648] New: - SWAP increases by the cluster of Tomca6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648
Summary: SWAP increases by the cluster of Tomca6
Product: Tomcat 6
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P4
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
SWAP increases by the cluster of Tomca6 and operation becomes unstable.
Environment
Tomcat6.0.13
JDK1.5.11
memory : 2G
Heap size : - Xmx1500m -Xms1500m
SWAP increases only for direct=true.
It occurs when operating for a long time by a high load.
Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver
...
direct=true /
SWAP doesn't increase when setting it to direct =false.
Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver
...
direct=false /
I noticed the following.
In org.apache.catalina.tribes.transport.nio.NioReplicationTask,buffer is made
per run method.
public synchronized void run() {
if ( (getOptions() OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
buffer = ByteBuffer.allocateDirect(getRxBufSize());
}else {
buffer = ByteBuffer.allocate (getRxBufSize());
}
if (key == null) {
return; // just in case
}
The buffer is enough if made once.
For instance,
The creating of buffer by the run method is stopped.
public synchronized void run() {
// if ( (getOptions() OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
//buffer = ByteBuffer.allocateDirect(getRxBufSize());
//}else {
//buffer = ByteBuffer.allocate (getRxBufSize());
//}
Creating of buffer by the setRxBufSize method.
public void setRxBufSize(int rxBufSize) {
this.rxBufSize = rxBufSize;
if ( (getOptions() OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
buffer = ByteBuffer.allocateDirect(getRxBufSize());
}else {
buffer = ByteBuffer.allocate (getRxBufSize());
}
}
Result.
SWAP doesn't increase.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42648] - SWAP increases by the cluster of Tomca6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42648. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42648 --- Additional Comments From [EMAIL PROTECTED] 2007-06-13 02:09 --- Created an attachment (id=20336) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20336action=view) abnormal cases abnormal cases. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42648] - SWAP increases by the cluster of Tomca6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42648. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42648 --- Additional Comments From [EMAIL PROTECTED] 2007-06-13 02:11 --- Created an attachment (id=20337) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20337action=view) normal cases normal cases. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed simplification of CometEvent
On Wed, 2007-06-13 at 12:04 +0200, Remy Maucherat wrote: Costin Manolache wrote: setTimeout() is not optional (the javadoc is out of date, sorry), there was an agreement on that earlier. Timeout sets the connection timeout, which is most likely useful even if there are events. It's quite possible sleep could use a timeout argument (I think calling setTimeout is more or less mandatory when using sleep, and OTOH calling setTimout is not as important otherwise). Ok - then sleep needs the extra argument, and will mean same as Thread.sleep(), but not-blocking ? This sleep is a non blocking call, and instructs the connection to do nothing until I wake you up (or a timeout occurs, of course). may be sleep is not the right name... Would suspend be a better name? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in
Mladen Turk wrote: Why? Let's stop a bit and test things before. Jean-Frédéric has of course done extended testing before proposing this :) The original patch was meant to close the security problem as soon as possible, but in the end has a bad behavior and should be reverted. Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I don't see how this can be a bad thing. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in
Remy Maucherat wrote: Mladen Turk wrote: Why? Let's stop a bit and test things before. Jean-Frédéric proposes implementing the same behavior as mod_proxy, so I don't see how this can be a bad thing. First of all I didn't said it's a bad thing or anything like that. We need the same behavior on Apache and IIS (at least), so this patch needs to be tested on IIS and Netscape as well. Also I think we should consider and discuss do we really need extra directive or it can be done by using existing or default. That's why I suggested to stop for a while and see all the possibilities. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544401 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring.xml
Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] so if we are not going to build the class, why would we include it in SVN and document it? It wont be part of the release. As has been going on in Jakarta-Commons, the release is the source release. The binary is just gravy:). The Connectors tree already (for a very long time), has conditional dependancies on the JDK used to compile. got it. then yes add it in...later :) once I announced that the tag would be created, a pile of checkins suddenly happened, and not properly tested. I'd rather see those checkins for after the tag. reasonable? My changes to the AJP Connectors are pretty much harmless for anything that currently works. Tomcat will do exactly the same thing it always has unless the request body is over 2GB. Currently, mod_jk can't handle this case anyway, and the reporter of BZ 42608 claims that mod_proxy_ajp can't either (but I can't see it myself). However, if you feel strongly about it, it is always your right to veto the commits :). we're good, I'll tag later today Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544401 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring.xml
Filip Hanik - Dev Lists wrote: My changes to the AJP Connectors are pretty much harmless for anything that currently works. Tomcat will do exactly the same thing it always has unless the request body is over 2GB. Currently, mod_jk can't handle this case anyway, and the reporter of BZ 42608 claims that mod_proxy_ajp can't either (but I can't see it myself). However, if you feel strongly about it, it is always your right to veto the commits :). we're good, I'll tag later today The patch does look good to me, and should probably be merged to all other branches. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546952 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Author: fhanik
Date: Wed Jun 13 09:55:27 2007
New Revision: 546952
URL: http://svn.apache.org/viewvc?view=revrev=546952
Log:
Fix for BZ 42648
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java?view=diffrev=546952r1=546951r2=546952
==
---
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Wed Jun 13 09:55:27 2007
@@ -63,12 +63,15 @@
// loop forever waiting for work to do
public synchronized void run() {
-if ( (getOptions() OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
-buffer = ByteBuffer.allocateDirect(getRxBufSize());
-}else {
-buffer = ByteBuffer.allocate (getRxBufSize());
+if ( buffer == null ) {
+if ( (getOptions() OPTION_DIRECT_BUFFER) ==
OPTION_DIRECT_BUFFER) {
+buffer = ByteBuffer.allocateDirect(getRxBufSize());
+} else {
+buffer = ByteBuffer.allocate(getRxBufSize());
+}
+} else {
+buffer.clear();
}
-
if (key == null) {
return;// just in case
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546955 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Author: fhanik
Date: Wed Jun 13 10:00:21 2007
New Revision: 546955
URL: http://svn.apache.org/viewvc?view=revrev=546955
Log:
fix for BZ 42648
http://issues.apache.org/bugzilla/show_bug.cgi?id=42648
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java?view=diffrev=546955r1=546954r2=546955
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
Wed Jun 13 10:00:21 2007
@@ -63,12 +63,15 @@
// loop forever waiting for work to do
public synchronized void run() {
-if ( (getOptions() OPTION_DIRECT_BUFFER) == OPTION_DIRECT_BUFFER ) {
-buffer = ByteBuffer.allocateDirect(getRxBufSize());
-}else {
-buffer = ByteBuffer.allocate (getRxBufSize());
+if ( buffer == null ) {
+if ( (getOptions() OPTION_DIRECT_BUFFER) ==
OPTION_DIRECT_BUFFER) {
+buffer = ByteBuffer.allocateDirect(getRxBufSize());
+} else {
+buffer = ByteBuffer.allocate(getRxBufSize());
+}
+} else {
+buffer.clear();
}
-
if (key == null) {
return;// just in case
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42648] - SWAP increases by the cluster of Tomca6
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42648. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42648 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-06-13 10:01 --- Basically, using allocateDirect, uses memory outside of your -Xmx and -Xms, since your Java heap(-Xmx) is so high, you have not left enough room for the direct memory. This is part of the Java memory model. However, you have discovered an optimization, that we don't need to create a new buffer and wait for GC to clean out the old one. So thanks for the notification, and remember that allocateDirect is memory outside of -Xmx memory space. Filip -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546958 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Author: fhanik
Date: Wed Jun 13 10:05:14 2007
New Revision: 546958
URL: http://svn.apache.org/viewvc?view=revrev=546958
Log:
fix for BZ 42650
http://issues.apache.org/bugzilla/show_bug.cgi?id=42650
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java?view=diffrev=546958r1=546957r2=546958
==
---
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Wed Jun 13 10:05:14 2007
@@ -44,12 +44,18 @@
public void sendMessage(Member[] destination, ChannelMessage message)
throws ChannelException {
if ( !connected ) throw new ChannelException(Sender not connected.);
ParallelNioSender sender = (ParallelNioSender)getSender();
-try {
-sender.sendMessage(destination, message);
-sender.keepalive();
-}finally {
-if ( !connected ) disconnect();
-returnSender(sender);
+if (sender == null) {
+ChannelException cx = new ChannelException(Unable to retrieve a
data sender, time out error.);
+for (int i = 0; i destination.length; i++)
cx.addFaultyMember(destination[i], new NullPointerException(Unable to retrieve
a sender from the sender pool));
+throw cx;
+} else {
+try {
+sender.sendMessage(destination, message);
+sender.keepalive();
+} finally {
+if (!connected) disconnect();
+returnSender(sender);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r546959 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Author: fhanik
Date: Wed Jun 13 10:07:06 2007
New Revision: 546959
URL: http://svn.apache.org/viewvc?view=revrev=546959
Log:
fix for BZ 42650
http://issues.apache.org/bugzilla/show_bug.cgi?id=42650
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java?view=diffrev=546959r1=546958r2=546959
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/PooledParallelSender.java
Wed Jun 13 10:07:06 2007
@@ -44,12 +44,18 @@
public void sendMessage(Member[] destination, ChannelMessage message)
throws ChannelException {
if ( !connected ) throw new ChannelException(Sender not connected.);
ParallelNioSender sender = (ParallelNioSender)getSender();
-try {
-sender.sendMessage(destination, message);
-sender.keepalive();
-}finally {
-if ( !connected ) disconnect();
-returnSender(sender);
+if (sender == null) {
+ChannelException cx = new ChannelException(Unable to retrieve a
data sender, time out error.);
+for (int i = 0; i destination.length; i++)
cx.addFaultyMember(destination[i], new NullPointerException(Unable to retrieve
a sender from the sender pool));
+throw cx;
+} else {
+try {
+sender.sendMessage(destination, message);
+sender.keepalive();
+} finally {
+if (!connected) disconnect();
+returnSender(sender);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42650] - PooledParallelSender.sendMessage throws NullpointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42650. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42650 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-06-13 10:14 --- Thanks for the bug report, consider increasing your sender pool, or find out why you are running out of them, or you can send messages asynchrously Filip -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed simplification of CometEvent
On 6/13/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: Costin Manolache wrote: For a separate opinion: In the trunk version: - the '...' and array return seem strange and generate GC ( not a big issue those days, but still inconsistent with the rest of tomcat ) yes, its a new language feature, hence it wasn't available in previous JDKs or Tomcat. its a vararg, if we don't want it we can switch to arrays, it works the same way. Yes, I know it's a vararg and my concern is not that it is not available in all VMs, but that it creates temp arrays and GC, which is inconsistent with the rest of tomcat which is very careful with creating objects. Also - it's quite useless in this particular case, printf is a good use case but that doesn't mean it should be used everywhere. - the API seems a bit over-complex - for example, why setConfiguration(COMMET_BLOCKING) instead of setBlocking() ? I agree that it less likely to break implementations by adding to the enom instead of adding methods to the interface - not sure why it's not an abstract class in the first place. if we want to simplify it, we would call it configureBlocking(boolean) - consistent with JDK APIs :) Sounds better - but as Remy explained you would first need to explain why blocking is needed in this context and how to deal with the confusion of mixing blocking and non-blocking for users, and the implementation complexities it adds. - please don't call the method configure(), it's commonly used with a different meaning ( i.e. setting the port or general configuration). setConnectionMode, etc. And using the enum doesn't sound consistent with other APIs either. we can call it whatever we want. But saying not using enum, its not consistent with other APIs in Tomcat, means would never take advantage of new language features ever, I think that would be a shame. Same as above - the question is not about using new features, but if the features fit the use. I have no problem with using enums for the event types - just for configure, in the context of configure(enum) versus setBlocking(), setFoo(). - see bellow - I don't think I understand the benefits of mixing blocking and non-blocking in this interface, it is quite confusing. It would be mixing it, its a one time config, during the BEGIN event, you say configureBlocking(true) or configureBlocking(false). Comet is very much connection centric, so you can't mix it. In the trunk API, its clear to what you are using, blocking or non blocking, in the sandbox API, the swap of it happens when invoking isWriteable or isReadable, making the state of the comet connection confusing to the developer. I'm not sure it's true - my understanding is that sandbox is all non-blocking. Invoking isWriteable is not blocking. I think it would be ok to add a blocking waitForEvent() - combined with isReadable()/isWriteable() it will allow a sort-of blocking model. But having methods that are blocking sometimes and sometimes not - based on some config - is dangerous and confusing. Costin Filip In the sandbox version: - sleep() and setTimeout(int) - why not sleep(int millis) ? I think it's confusing to have both and the interactions between them, in particular setTimeout is marked optional ? It makes sense to have setTimeout() as a general timeout. - not sure I understand the use case for isReadable()/isWriteable() - when will this be called ? My understanding was that when the connection is readable, a callback will be generated with EventType == READ. Also it's very confusing to mix the 'blocking' in the isReadable()/isWriteable() - it would be much cleaner to say that the connection is always non-blocking, and add a method to switch to blocking mode ( then use the regular servlet methods maybe ). Using the ComentEvent for both is IMHO dangerous. - will sleep() still allow callbacks ( and if not - what will happen with them )? What's going to happen with callbacks if callback() is not called ? In general ( both versions): - it would be great to move it from o.a.catalina to org.apache.comet Costin On 6/11/07, Remy Maucherat [EMAIL PROTECTED] wrote: Filip Hanik - Dev Lists wrote: Ok, let me see if I can summarize. 1. Whether you write out the stored buffer using the Poller thread, or a Tomcat worker thread (flushed in Http11xxxProcessor) as described below I originally thought of this as async write, as we are simply doing a write with another one of our threads. Originally when we were talking non blocking writes, I was thinking along the lines of non blocking to where the Comet developer had to do that logic, just as he was writing a socket, possibly like (but not suggested) a CometEvent.nonBlockWrite(ByteBuffer). 2. Do we need non blocking? with the methods of isWriteable and the ability to register(OP_WRITE)-event(WRITE), if the number of bytes you write is usually smaller than the socket buffer, chances are
Re: Proposed simplification of CometEvent
On 6/13/07, Remy Maucherat [EMAIL PROTECTED] wrote: Costin Manolache wrote: setTimeout() is not optional (the javadoc is out of date, sorry), there was an agreement on that earlier. Timeout sets the connection timeout, which is most likely useful even if there are events. It's quite possible sleep could use a timeout argument (I think calling setTimeout is more or less mandatory when using sleep, and OTOH calling setTimout is not as important otherwise). Ok - then sleep needs the extra argument, and will mean same as Thread.sleep(), but not-blocking ? This sleep is a non blocking call, and instructs the connection to do nothing until I wake you up (or a timeout occurs, of course). Please add this to the javadoc :-) And maybe call it 'setTimerEvent(timeMillis)' or something like that - to avoid confusion with Thread.sleep() which is blocking the thread. IMHO it would be very nice to also have a blocking waitForEvent(timeMillis) - as an alternative to adding blocking mode as in the trunk. Although the read event indicates there's data to read, isReadable indicates if it is possible to continue reading. My understanding was that the InputStream in request is used for actual reading - and available() could do the same thing. What is the difference then between the 2 ? isReadable is the same as is.available (and reader.ready). It's there for a bit of symmetry after adding isWriteable, which may or may not be useful, and I didn't care about it. Why not call it available() and return the same as the servlet method ? I think it's ok to have 'shortcuts' in the CometEvent - even read()/write() methods that would expose more efficient ways to send/get data than the InputStream. isWriteable indicates if the last write operation managed to write more than 0 bytes. If the last write wrote 0, then isWriteable will return false, so the servlet knows it should stop writing on this connection for now (since it cannot accept any output at the moment). Later on, the servlet will receive a write event, and can resume writing. I'm still a bit confused about this - my understanding was that write event means the previous buffers were written, and you can write more. There are some buffers on the OS side as well as buffers on the connector side. Yes, it means that: the servlet gets a write event, which means it can start writing again. What do you mean by 'managed to write more than 0 bytes' - the write in the OutputStream can go to some of the buffers, or to the client. I assume you don't mean the client ( due to TCP delays ). I was talking about the actual write on the socket (in APR, it's done in InternalAprOutputBuffer.flushBuffer), which may return 0. At the servlet layer, as per the contract of the OutputStream API, is must write everything or fail, and this isn't going to change. Where 'write everything' means 'maybe buffer some of it at OS or java layer'. Could you add more javadocs on how much can you expect to write if isWriteable() returns true ? Since the OutputStream method doesn't support partial writes - I suppose this would help more than isWriteable. - If doing synchronous writes inside some event (either a read or callback event, most likely), then both blocking and non blocking mode make sense. Some servlets may prefer to use blocking mode although it could be holding a thread for a while (for example if the idea is only maybe a 'waitForEvent()' method to allow a servlet to block if he wants to ? Or is sleep() supposed to do this - I'm not sure from the comments if sleep() will block or just triger an event when the interval expires ? Sleep will by itself only trigger timeout events (the method call itself will return immediately). The servlet can use the callback method to trigger an event before the timeout occurs. You mean sort of 'notify()' - i.e. someone calls callback() and will trigger the servlet to be executed, interrupting any sleep or wait ? Originally, this was indeed supposed to be called notify, but it's not possible due to Object.notify :( If you have another name to suggest to replace callback ... Well - servletNotify() or servletWakeup() or sendCometEvent() ? Costin In general ( both versions): - it would be great to move it from o.a.catalina to org.apache.comet It's a possibility. I think more comments and examples ( and maybe better names ) would be great. I think there's going to be some code using Comet soon. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547022 - /tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_24/
Author: fhanik Date: Wed Jun 13 13:47:56 2007 New Revision: 547022 URL: http://svn.apache.org/viewvc?view=revrev=547022 Log: Tagging Tomcat version TOMCAT_5_5_24. Added: tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_24/ - copied from r547021, tomcat/connectors/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547023 - /tomcat/container/tags/tc5.5.x/TOMCAT_5_5_24/
Author: fhanik Date: Wed Jun 13 13:48:06 2007 New Revision: 547023 URL: http://svn.apache.org/viewvc?view=revrev=547023 Log: Tagging Tomcat version TOMCAT_5_5_24. Added: tomcat/container/tags/tc5.5.x/TOMCAT_5_5_24/ - copied from r547022, tomcat/container/tc5.5.x/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547025 - /tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_24/
Author: fhanik Date: Wed Jun 13 13:48:26 2007 New Revision: 547025 URL: http://svn.apache.org/viewvc?view=revrev=547025 Log: Tagging Tomcat version TOMCAT_5_5_24. Added: tomcat/servletapi/tags/servlet2.4-jsp2.0-tc5.x/TOMCAT_5_5_24/ - copied from r547024, tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547026 - /tomcat/site/tags/TOMCAT_5_5_24/
Author: fhanik Date: Wed Jun 13 13:48:36 2007 New Revision: 547026 URL: http://svn.apache.org/viewvc?view=revrev=547026 Log: Tagging Tomcat version TOMCAT_5_5_24. Added: tomcat/site/tags/TOMCAT_5_5_24/ - copied from r547025, tomcat/site/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.5.24 candidate binaries
http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.24/ will let these sit to mid next week, and then we can take a vote. feedback between now and then is welcome at any time. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547055 - /tomcat/trunk/webapps/docs/aio.xml
Author: fhanik
Date: Wed Jun 13 15:51:56 2007
New Revision: 547055
URL: http://svn.apache.org/viewvc?view=revrev=547055
Log:
added simple example code snippets to comet usage
Modified:
tomcat/trunk/webapps/docs/aio.xml
Modified: tomcat/trunk/webapps/docs/aio.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diffrev=547055r1=547054r2=547055
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Wed Jun 13 15:51:56 2007
@@ -151,6 +151,26 @@
/source
/p
/subsection
+ subsection name=Comet Operations
+ p
+The previous section touched a little bit on the comet connection
lifecycle.
+It is important to remember that comet events are based around IO on an
actual socket.br/
+To clarify the Comet API, it has been created to resemble the java.nio
channel/selector APIs.
+In the case of Comet, Tomcat is the selector and using the CometEvent
object, you can
+register and unregister your Comet event for different event type
notifications.
+We call the parameter to the codeCometEvent.register/unregister/code
method a comet operation.
+This is similar to the interestOps method of a codeSelectionKey/code
in the java.nio implementation.
+br/The Comet implementation of register and unregister has been greatly
simplified to not force the
+comet developer to implement complex synchronizations around the register
and unregister code.
+ /p
+ p
+It is important to realize, just like the java.nio API, that once an
operation has been registered, it will
+remain registered until it is unregistered. If you have registered
OP_READ, then the comet connection will
+fire READ events, every time data arrives until your unregister the
OP_READ operation.br/
+OP_CALLBACK/OP_WRITE work in the same way, essentially,
register(OP_CALLBACK|OP_WRITE) will keep spawning
+CALLBACK/WRITE events until you unregister the operation(s).
+ /p
+ /subsection
subsection name=CometEvent
@@ -261,8 +281,269 @@
/subsection
- subsection name=Example code
+ subsection name=Example code snippets
+ p
+Imagine you are writing a servlet that is updating a set of
+stock tickers. You have a back ground thread that is receiving
+updates for tickers as they happen, and you wish to push out these
+to all the tickers that have the stocks in their list.br/
+In the following example, you can accomplish maximum through put by
+taking advantage of Tomcat's non blocking Comet features.br/
+When the StockUpdater thread is running, it receives a set of stock
updates.
+It gets all the clients that are registered for the stocks that have
changed.br/
+For each client, there is an associated CometEvent object, the StockUpdater
+checks if it can write without blocking, if so it writes directly,
otherwise
+it registers the client for a WRITE event, that will tell the
+system that we can write the data now.
+This is a perfect example of how we can take advantage of the combination
of the write event
+and the isWriteable method to determine, when we can write the data.br/
+As with any kind of non blocking IO, you will need to synchronize your
code,
+this has not been done in the example below since the focus is on the
+data delivery, not synchronization.
+ /p
+ source
+public class ExampleCometStockStreamer implements CometProcessor {
+ ...
+ public class StockUpdater extends Thread {
+public void run() {
+ ...
+ StockUpdates[] updates = fetchUpdates();
+ Client[] clients = getClients(updates);
+ for (int i=0; ilt;clients.length; i++ ) {
+CometEvent event = client.getEvent();
+StockUpdates[] clientList = getClientUpdates(client,updates);
+client.setAndMergeNextUpdates(clientList);
+if (event.isWriteable()) {
+ byte[] data = getUpdateChunk(client.getNextUpdates());
+ event.getHttpServletResponse().getOutputStream().write(data);
+} else {
+ event.register(OP_WRITE);
+}
+ }
+ ...
+}
+ }
+ ...
+ public void event(CometEvent event) throws IOException, ServletException {
+...
+if ( event.getEventType() == CometEvent.EventType.BEGIN ) {
+ //configure non blocking
+ event.configureBlocking(false);
+} if ( event.getEventType() == CometEvent.EventType.READ ) {
+ //read client Id and stock list from client
+ //and add the event to our list
+ String clientId = readClientInfo(event,stocks);
+ clients.add(clientId, event, stocks);
+} if ( event.getEventType() == CometEvent.EventType.WRITE ) {
+ //unregister from the write event
+ event.unregister(OP_WRITE);
+ //we can now write
+ byte[] data = getUpdateChunk(client.getNextUpdates());
+
Re: Proposed simplification of CometEvent
here we go, some examples http://people.apache.org/~fhanik/tomcat/aio.html#Example%20code%20snippets and the entire document has been updated to reflect most changes http://people.apache.org/~fhanik/tomcat/aio.html Filip Filip Hanik - Dev Lists wrote: I'll work on some examples to illustrate what I mean, It will be much clearer Filip Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Ok, let me see if I can summarize. 1. Whether you write out the stored buffer using the Poller thread, or a Tomcat worker thread (flushed in Http11xxxProcessor) as described below I originally thought of this as async write, as we are simply doing a write with another one of our threads. Originally when we were talking non blocking writes, I was thinking along the lines of non blocking to where the Comet developer had to do that logic, just as he was writing a socket, possibly like (but not suggested) a CometEvent.nonBlockWrite(ByteBuffer). 2. Do we need non blocking? with the methods of isWriteable and the ability to register(OP_WRITE)-event(WRITE), if the number of bytes you write is usually smaller than the socket buffer, chances are that most writes will be non blocking. I would even argue a large majority would be non blocking, and thus the implementation or the complexity thereof would not be needed. And with the ability to do async writes, means I can create my own thread pool/write queue to perform these writes. You are writing the opposite thing to the previous email, and we are back to non blocking is useless. The problem is that I understand blocking IO as write this data, and return when it's done. If the socket is in blocking mode, any write done by the servlet may block, regardless of what isWriteable says. Of course, it's very unlikely, which is why Comet in 6.0.x works. 3. isWriteable - simple method, but I don't like that the method in itself performs actions like adding the socket to a poller etc. Instead isWriteable==true means that you can write on the socket, isWriteable==false you cannot. This method should be able to be invoked as many times as its wanted, and is thread safe and doesn't do anything funky underneath. Ok, so you prefer a more complex API (if I follow just in case it was useful). I started with an API which would expose all operations, and looked into removing what was not explicitly useful. 4. isWriteable - I'm also reading in that you are also suggesting that we use this method to declare if we want blocking or non blocking writes. No. The situation where write could (maybe) block is if the servlet writes in a Tomcat thread. Typically, this is the reply-later design, using the sleep/callback methods. The isWriteable method is not used, since the servlet merely wants (in that common design) to send a response as fast as possible, and typically this sort of response is not too large and unlikely to cause IO problems. This blocking behavior is allowed in that case to avoid forcing the user to put in more complex logic to deal with the partial write + event, and is set just for the amount of time it takes to perform the write (note that this ). At this point this method is doing three things: a) returns true/false if we can write data b) delegates a socket to the poller to write data and generate a event(WRITE) to the comet processor c) configures a write to be blocking or non blocking This is for sure not what I would expect of a simple API, if simple means less keystrokes than yes, but simple to me also means intuitive and easily understood. So you have plenty of methods to do the same thing. Given points 1-4, this is what is going to happen to every single developer I) They are going to use stream.write and event.isWriteable all the time, not realizing what it actually does II) They are going to get confused when they receive an IOException for trying to perform a write, cause they used isWriteable and the socket went into non blocking mode If that's what you want to believe ... At this point, this 'simple' API, obviously not so simple, instead it becomes very complicated, as I would almost have to reverse engineer the code to truly understand what it does. It may be simple to you and me, but that is because we are implementing it. I really don't see what is complex, especially when you look at the code the user would write for the simple cases, where you don't even have to use any API besides stream.write: - reply later - wait for read events, and write data in response to it The complex case deals with handling incomplete async writes if you don't simply drop connection. so what does this mean to 'isReadable'? That I'm automatically registering for a READ event if it returns false? Maybe I don't want a READ event, I just want to see if any data has trickled in. so if I call sleep(), should I then call isReadable() to reregister for the read. how is this simpler than that
Re: Proposed simplification of CometEvent
Sounds better - but as Remy explained you would first need to explain why blocking is needed in this context and how to deal with the confusion of mixing blocking and non-blocking for users, and the implementation complexities it adds. trunk doesn't mix them. a comet connection is either blocking or non blocking, it doesn't shift between the two, and it allows developers to choose what they want. Just like a SocketChannel in java.nio. there is nothing confusing about that, unless java.nio is confusing :) Well, nio is far from perfect - but that's not the point. Servlets have a very nice blocking mechanism already - it's the servlet API :-). The question is why would you need to have a Commet connection blocking. I think it's very reasonable to add a blocking waitForEvent() to allow servlets have a simpler ( but less efficient ) implementation. Think about utilities that take the event as param - would they need to check first if it's blocking or not ? And what would blocking give you in addition to waitForEvent() - which is actually better since it allows you to un-block on any event, not only a specific read/write. - please don't call the method configure(), it's commonly used with a different meaning ( i.e. setting the port or general configuration). setConnectionMode, etc. And using the enum doesn't sound consistent with other APIs either. we can call it whatever we want. But saying not using enum, its not consistent with other APIs in Tomcat, means would never take advantage of new language features ever, I think that would be a shame. Same as above - the question is not about using new features, but if the features fit the use. I have no problem with using enums for the event types - just for configure, in the context of configure(enum) versus setBlocking(), setFoo(). this has been adjusted based on the feedback, the method is now configureBlocking(boolean) the state of it can be used by calling isBlocking() register is using enums, mainly cause Remy, while he was working with this API insisted on it. I had preferred using an int, just like the socket API, but since Remy had initially agreed to register, and proposed enum and unregister we went with that. Ok. - see bellow - I don't think I understand the benefits of mixing blocking and non-blocking in this interface, it is quite confusing. It would be mixing it, its a one time config, during the BEGIN event, you say configureBlocking(true) or configureBlocking(false). Comet is very much connection centric, so you can't mix it. In the trunk API, its clear to what you are using, blocking or non blocking, in the sandbox API, the swap of it happens when invoking isWriteable or isReadable, making the state of the comet connection confusing to the developer. I'm not sure it's true - my understanding is that sandbox is all non-blocking. Invoking isWriteable is not blocking. I think it would be ok to add a blocking waitForEvent() - combined with isReadable()/isWriteable() this would be a dead lock, as the Comet API must guarantee that a CometProcessor.event is only invoked by one worker thread at any time. The blocking you are talking about can be done using an async thread can be done by registering for the event you wish to be notified in and then maybe await a latch countdown, or doing a sync/wait() combo. What would happen in the blocking case when a different event happens ? Isn't it the same, if you want to guarantee single-threaded behaviour ? Well - is there any docs on what is the intended thread model of comet servlets, i.e. SingelThreaded or reentrant ? Multiple events can happen at same time ( or very close - one event soon after a Comet servlet is called, before it returns), so this is a general problem. it will allow a sort-of blocking model. But having methods that are blocking sometimes and sometimes not - based on some config - is dangerous and confusing. As I mentioned, the trunk Comet API is actually very similar to java.nio API, hence developers familiar with that will instantly recognize themselves and should get comfortable with the API. I still don't recognize it as NIO :-), and I am not very comfortable with the changes between blocking and non-blocking in NIO ( including all the crazy things that can happen only in the IO thread ). Here are some of the things that might need to be clarified about the trunk API: 1. It is possible to not be registered for any events, and even do polling for data asynchronously You would still get the BEGIN event I assume. All you need to poll data async is waitForEvent(), or select() if you like to emulate nio. 2. ERROR and END events, are an exception, you cant unregister for those, as those might require the underlying socket to be closed, or has already been closed In what thread would you get those ( in blocking mode ?) 5. The current READ event in CoyoteAdapter ends up performing a blocking
svn commit: r547077 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager: HTMLManagerServlet.java host/HTMLHostManagerServlet.java
Author: markt
Date: Wed Jun 13 18:55:09 2007
New Revision: 547077
URL: http://svn.apache.org/viewvc?view=revrev=547077
Log:
Fix XSS issue in Manager and Host Manager. This is CVE-2007-2450.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java?view=diffrev=547077r1=547076r2=547077
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
Wed Jun 13 18:55:09 2007
@@ -130,8 +130,7 @@
message = stop(path);
} else {
message =
-sm.getString(managerServlet.unknownCommand,
- RequestUtil.filter(command));
+sm.getString(managerServlet.unknownCommand, command);
}
list(request, response, message);
@@ -305,7 +304,11 @@
// Message Section
args = new Object[3];
args[0] = sm.getString(htmlManagerServlet.messageLabel);
-args[1] = (message == null || message.length() == 0) ? OK : message;
+if (message == null || message.length() == 0) {
+args[1] = OK;
+} else {
+args[1] = RequestUtil.filter(message);
+}
writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
// Manager Section
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java?view=diffrev=547077r1=547076r2=547077
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/host/HTMLHostManagerServlet.java
Wed Jun 13 18:55:09 2007
@@ -32,6 +32,7 @@
import org.apache.catalina.Container;
import org.apache.catalina.Host;
+import org.apache.catalina.util.RequestUtil;
import org.apache.catalina.util.ServerInfo;
/**
@@ -195,7 +196,11 @@
// Message Section
args = new Object[3];
args[0] = sm.getString(htmlHostManagerServlet.messageLabel);
-args[1] = (message == null || message.length() == 0) ? OK : message;
+if (message == null || message.length() == 0) {
+args[1] = OK;
+} else {
+args[1] = RequestUtil.filter(message);
+}
writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
// Manager Section
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547078 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/ajp/AjpAprProcessor.java coyote/ajp/AjpProcessor.java jk/common/HandlerRequest.java
Author: billbarker
Date: Wed Jun 13 18:56:16 2007
New Revision: 547078
URL: http://svn.apache.org/viewvc?view=revrev=547078
Log:
Porting large-file support for the AJP Connectors from 5.5
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diffrev=547078r1=547077r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed
Jun 13 18:56:16 2007
@@ -680,7 +680,9 @@
if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
} else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
@@ -1204,7 +1206,7 @@
if (endOfStream) {
return -1;
}
-if (first req.getContentLength() 0) {
+if (first req.getContentLengthLong() 0) {
// Handle special first-body-chunk
if (!receive()) {
return 0;
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?view=diffrev=547078r1=547077r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Wed Jun
13 18:56:16 2007
@@ -688,7 +688,9 @@
if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
} else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
@@ -1144,7 +1146,7 @@
if (endOfStream) {
return -1;
}
-if (first req.getContentLength() 0) {
+if (first req.getContentLengthLong() 0) {
// Handle special first-body-chunk
if (!receive()) {
return 0;
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java?view=diffrev=547078r1=547077r2=547078
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/HandlerRequest.java Wed Jun
13 18:56:16 2007
@@ -407,7 +407,7 @@
// Check to see if there should be a body packet coming along
// immediately after
-int cl=req.getContentLength();
+long cl=req.getContentLengthLong();
if(cl 0) {
JkInputStream jkIS = ep.getInputStream();
jkIS.setIsReadRequired(true);
@@ -577,7 +577,9 @@
if (hId == AjpConstants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-req.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+req.setContentLength( (int)cl );
} else if (hId == AjpConstants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547079 - /tomcat/tc6.0.x/trunk/
Author: markt Date: Wed Jun 13 18:57:01 2007 New Revision: 547079 URL: http://svn.apache.org/viewvc?view=revrev=547079 Log: Ignore local build properties Modified: tomcat/tc6.0.x/trunk/ (props changed) Propchange: tomcat/tc6.0.x/trunk/ -- --- svn:ignore (original) +++ svn:ignore Wed Jun 13 18:57:01 2007 @@ -1,2 +1,3 @@ output .settings +build.properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547081 - in /tomcat/tc6.0.x/trunk/webapps/examples/jsp: security/protected/index.jsp snp/snoop.html snp/snoop.jsp source.jsp
Author: markt
Date: Wed Jun 13 19:01:19 2007
New Revision: 547081
URL: http://svn.apache.org/viewvc?view=revrev=547081
Log:
Fix XSS issues in snoop.jsp. This is CVE-2007-2449. Some of these are harder
(impossible?) to exploit than others but doing all of them means there won't be
another XSS issue to patch later.
I also made a similar change for a couple of other JSPs that are in the
harder/impossible? to exploit category.
Modified:
tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp
tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html
tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp
tomcat/tc6.0.x/trunk/webapps/examples/jsp/source.jsp
Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp?view=diffrev=547081r1=547080r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp
(original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/security/protected/index.jsp Wed
Jun 13 19:01:19 2007
@@ -27,14 +27,16 @@
/head
body bgcolor=white
-You are logged in as remote user b%= request.getRemoteUser() %/b
+You are logged in as remote user
+b%= util.HTMLFilter.filter(request.getRemoteUser()) %/b
in session b%= session.getId() %/bbrbr
%
if (request.getUserPrincipal() != null) {
%
Your user principal name is
-b%= request.getUserPrincipal().getName() %/bbrbr
+b%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %/b
+brbr
%
} else {
%
Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html?view=diffrev=547081r1=547080r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html (original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.html Wed Jun 13
19:01:19 2007
@@ -24,8 +24,8 @@
body bgcolor=#FF
pfont color=#FFa href=snoop.jspimg src=../images/execute.gif
align=right border=0/aa href=../index.htmlimg
src=../images/return.gif width=24 height=24 align=right
border=0/a/font/p
-h3a href=snoop.jsp.htmlSource Code for Request Parameters Examplefont
color=#FF/a
- /font /h3
+h3a href=snoop.jsp.htmlSource Code for Request Parameters Examplefont
color=#FF
+ /font/a/h3
/body
/html
Modified: tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp?view=diffrev=547081r1=547080r2=547081
==
--- tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp (original)
+++ tomcat/tc6.0.x/trunk/webapps/examples/jsp/snp/snoop.jsp Wed Jun 13 19:01:19
2007
@@ -19,37 +19,38 @@
body bgcolor=white
h1 Request Information /h1
font size=4
-JSP Request Method: % out.print(util.HTMLFilter.filter(request.getMethod()));
%
+JSP Request Method: %= util.HTMLFilter.filter(request.getMethod()) %
br
-Request URI: %= request.getRequestURI() %
+Request URI: %= util.HTMLFilter.filter(request.getRequestURI()) %
br
-Request Protocol: %= request.getProtocol() %
+Request Protocol: %= util.HTMLFilter.filter(request.getProtocol()) %
br
-Servlet path: %= request.getServletPath() %
+Servlet path: %= util.HTMLFilter.filter(request.getServletPath()) %
br
-Path info: % out.print(util.HTMLFilter.filter(request.getPathInfo())); %
+Path info: %= util.HTMLFilter.filter(request.getPathInfo()) %
br
-Query string: % out.print(util.HTMLFilter.filter(request.getQueryString()));
%
+Query string: %= util.HTMLFilter.filter(request.getQueryString()) %
br
Content length: %= request.getContentLength() %
br
-Content type: % out.print(util.HTMLFilter.filter(request.getContentType()));
%
+Content type: %= util.HTMLFilter.filter(request.getContentType()) %
br
-Server name: %= request.getServerName() %
+Server name: %= util.HTMLFilter.filter(request.getServerName()) %
br
Server port: %= request.getServerPort() %
br
-Remote user: %= request.getRemoteUser() %
+Remote user: %= util.HTMLFilter.filter(request.getRemoteUser()) %
br
-Remote address: %= request.getRemoteAddr() %
+Remote address: %= util.HTMLFilter.filter(request.getRemoteAddr()) %
br
-Remote host: %= request.getRemoteHost() %
+Remote host: %= util.HTMLFilter.filter(request.getRemoteHost()) %
br
-Authorization scheme: %= request.getAuthType() %
+Authorization scheme: %= util.HTMLFilter.filter(request.getAuthType()) %
br
Locale: %= request.getLocale() %
hr
-The browser you are using is %
out.print(util.HTMLFilter.filter(request.getHeader(User-Agent))); %
+The browser you are using is
+%= util.HTMLFilter.filter(request.getHeader(User-Agent)) %
hr
/font
/body
Modified:
svn commit: r547083 - in /tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples: security/protected/index.jsp snp/snoop.html snp/snoop.jsp source.jsp
Author: markt
Date: Wed Jun 13 19:12:38 2007
New Revision: 547083
URL: http://svn.apache.org/viewvc?view=revrev=547083
Log:
Port fix for XSS issues in snoop.jsp. This is CVE-2007-2449.
Modified:
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/source.jsp
Modified:
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
URL:
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp?view=diffrev=547083r1=547082r2=547083
==
---
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
(original)
+++
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
Wed Jun 13 19:12:38 2007
@@ -27,14 +27,16 @@
/head
body bgcolor=white
-You are logged in as remote user b%= request.getRemoteUser() %/b
+You are logged in as remote user
+b%= util.HTMLFilter.filter(request.getRemoteUser()) %/b
in session b%= session.getId() %/bbrbr
%
if (request.getUserPrincipal() != null) {
%
Your user principal name is
-b%= request.getUserPrincipal().getName() %/bbrbr
+b%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %/b
+brbr
%
} else {
%
Modified:
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
URL:
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html?view=diffrev=547083r1=547082r2=547083
==
--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
(original)
+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.html
Wed Jun 13 19:12:38 2007
@@ -24,8 +24,8 @@
body bgcolor=#FF
pfont color=#FFa href=snoop.jspimg src=../images/execute.gif
align=right border=0/aa href=../index.htmlimg
src=../images/return.gif width=24 height=24 align=right
border=0/a/font/p
-h3a href=snoop.jsp.htmlSource Code for Request Parameters Examplefont
color=#FF/a
- /font /h3
+h3a href=snoop.jsp.htmlSource Code for Request Parameters Examplefont
color=#FF
+ /font/a/h3
/body
/html
Modified:
tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp
URL:
http://svn.apache.org/viewvc/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp?view=diffrev=547083r1=547082r2=547083
==
--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp
(original)
+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/snp/snoop.jsp Wed
Jun 13 19:12:38 2007
@@ -19,37 +19,38 @@
body bgcolor=white
h1 Request Information /h1
font size=4
-JSP Request Method: % out.print(util.HTMLFilter.filter(request.getMethod()));
%
+JSP Request Method: %= util.HTMLFilter.filter(request.getMethod()) %
br
-Request URI: %= request.getRequestURI() %
+Request URI: %= util.HTMLFilter.filter(request.getRequestURI()) %
br
-Request Protocol: %= request.getProtocol() %
+Request Protocol: %= util.HTMLFilter.filter(request.getProtocol()) %
br
-Servlet path: %= request.getServletPath() %
+Servlet path: %= util.HTMLFilter.filter(request.getServletPath()) %
br
-Path info: % out.print(util.HTMLFilter.filter(request.getPathInfo())); %
+Path info: %= util.HTMLFilter.filter(request.getPathInfo()) %
br
-Query string: % out.print(util.HTMLFilter.filter(request.getQueryString()));
%
+Query string: %= util.HTMLFilter.filter(request.getQueryString()) %
br
Content length: %= request.getContentLength() %
br
-Content type: % out.print(util.HTMLFilter.filter(request.getContentType()));
%
+Content type: %= util.HTMLFilter.filter(request.getContentType()) %
br
-Server name: %= request.getServerName() %
+Server name: %= util.HTMLFilter.filter(request.getServerName()) %
br
Server port: %= request.getServerPort() %
br
-Remote user: %= request.getRemoteUser() %
+Remote user: %= util.HTMLFilter.filter(request.getRemoteUser()) %
br
-Remote address: %= request.getRemoteAddr() %
+Remote address: %= util.HTMLFilter.filter(request.getRemoteAddr()) %
br
-Remote host: %= request.getRemoteHost() %
+Remote host: %= util.HTMLFilter.filter(request.getRemoteHost()) %
br
-Authorization scheme: %= request.getAuthType() %
+Authorization scheme: %= util.HTMLFilter.filter(request.getAuthType()) %
br
Locale: %= request.getLocale() %
hr
-The browser you are using is %
out.print(util.HTMLFilter.filter(request.getHeader(User-Agent))); %
+The browser you are using is
+%= util.HTMLFilter.filter(request.getHeader(User-Agent)) %
hr
/font
/body
Modified:
svn commit: r547085 - /tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Author: markt
Date: Wed Jun 13 19:13:59 2007
New Revision: 547085
URL: http://svn.apache.org/viewvc?view=revrev=547085
Log:
Port fix for XSS issue in Manager. This is CVE-2007-2450.
Modified:
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Modified:
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java?view=diffrev=547085r1=547084r2=547085
==
---
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
(original)
+++
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
Wed Jun 13 19:13:59 2007
@@ -113,8 +113,7 @@
message = stop(path);
} else {
message =
-sm.getString(managerServlet.unknownCommand,
- RequestUtil.filter(command));
+sm.getString(managerServlet.unknownCommand,command);
}
list(request, response, message);
@@ -317,7 +316,11 @@
// Message Section
args = new Object[3];
args[0] = sm.getString(htmlManagerServlet.messageLabel);
-args[1] = (message == null || message.length() == 0) ? OK : message;
+if (message == null || message.length() == 0) {
+args[1] = OK;
+} else {
+args[1] = RequestUtil.filter(message);
+}
writer.print(MessageFormat.format(MESSAGE_SECTION, args));
// Manager Section
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547087 - in /tomcat/container/branches/tc4.1.x/webapps/examples/jsp: security/protected/index.jsp snp/snoop.html snp/snoop.jsp snp/snoop.txt source.jsp
Author: markt
Date: Wed Jun 13 19:14:55 2007
New Revision: 547087
URL: http://svn.apache.org/viewvc?view=revrev=547087
Log:
Port fix for XSS issues in snoop.jsp. This is CVE-2007-2449.
Modified:
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.txt
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/source.jsp
Modified:
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp?view=diffrev=547087r1=547086r2=547087
==
---
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
(original)
+++
tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jsp
Wed Jun 13 19:14:55 2007
@@ -1,3 +1,19 @@
+!--
+ 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.
+--
%
if (request.getParameter(logoff) != null) {
session.invalidate();
@@ -11,14 +27,16 @@
/head
body bgcolor=white
-You are logged in as remote user b%= request.getRemoteUser() %/b
+You are logged in as remote user
+b%= util.HTMLFilter.filter(request.getRemoteUser()) %/b
in session b%= session.getId() %/bbrbr
%
if (request.getUserPrincipal() != null) {
%
Your user principal name is
-b%= request.getUserPrincipal().getName() %/bbrbr
+b%= util.HTMLFilter.filter(request.getUserPrincipal().getName()) %/b
+brbr
%
} else {
%
Modified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html?view=diffrev=547087r1=547086r2=547087
==
--- tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html
(original)
+++ tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.html Wed
Jun 13 19:14:55 2007
@@ -1,7 +1,19 @@
html
!--
- Copyright (c) 1999 The Apache Software Foundation. All rights
- reserved.
+ 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.
--
head
@@ -10,10 +22,10 @@
/head
body bgcolor=#FF
-pfont color=#FFa href=snoop.jspimg
src=../../images/execute.gif align=right border=0/aa
href=../index.htmlimg src=../../images/return.gif width=24 height=24
align=right border=0/a/font/p
+pfont color=#FFa href=snoop.jspimg src=../images/execute.gif
align=right border=0/aa href=../index.htmlimg
src=../images/return.gif width=24 height=24 align=right
border=0/a/font/p
-h3a href=snoop.txtSource Code for Request Parameters Examplefont
color=#FF/a
- /font /h3
+h3a href=snoop.jsp.htmlSource Code for Request Parameters Examplefont
color=#FF
+ /font/a/h3
/body
/html
Modified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp?view=diffrev=547087r1=547086r2=547087
==
--- tomcat/container/branches/tc4.1.x/webapps/examples/jsp/snp/snoop.jsp
(original)
+++
svn commit: r547088 - /tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
Author: markt
Date: Wed Jun 13 19:17:22 2007
New Revision: 547088
URL: http://svn.apache.org/viewvc?view=revrev=547088
Log:
Port fix for XSS issue in Manager. This is CVE-2007-2450.
Modified:
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
Modified:
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java?view=diffrev=547088r1=547087r2=547088
==
---
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
(original)
+++
tomcat/container/branches/tc5.0.x/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java
Wed Jun 13 19:17:22 2007
@@ -106,9 +106,7 @@
} else if (command.equals(/stop)) {
message = stop(path);
} else {
-message =
-sm.getString(managerServlet.unknownCommand,
-RequestUtil.filter(command));
+message = sm.getString(managerServlet.unknownCommand, command);
}
list(request, response, message);
@@ -306,7 +304,11 @@
// Message Section
args = new Object[3];
args[0] = sm.getString(htmlManagerServlet.messageLabel);
-args[1] = (message == null || message.length() == 0) ? OK : message;
+if (message == null || message.length() == 0) {
+args[1] = OK;
+} else {
+args[1] = RequestUtil.filter(message);
+}
writer.print(MessageFormat.format(Constants.MESSAGE_SECTION, args));
// Manager Section
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[CVE-2007-2449] Apache Tomcat XSS vulnerabilities in the JSP examples
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2007-2449: Apache Tomcat XSS vulnerabilities in the JSP examples Severity: low (cross-site scripting) Vendor: The Apache Software Foundation Versions Affected: Tomcat 4.0.0 to 4.0.6 Tomcat 4.1.0 to 4.1.36 Tomcat 5.0.0 to 5.0.30 Tomcat 5.5.0 to 5.5.24 Tomcat 6.0.0 to 6.0.13 Description: The JSP examples web application displays does not escape some user provided data before including it in the output. This enables a XSS attack. Mitigation: 1. Undeploy the examples web application(s). Example: http://host:port/jsp-examples/snp/snoop.jsp;scriptalert()/scripttest.jsp Credit: These issues were discovered by an unknown security researcher and reported to JPCERT. References: http://tomcat.apache.org/security.html Mark Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcKbJb7IeiTPGAkMRAi9BAKDsuoomGh2n9BYl7mT/tGEjQ+HIlQCdHjnU zdreMwViLR/bDBnys5YkhPk= =SK7+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547096 - in /tomcat/trunk/java/org/apache: coyote/ajp/AjpAprProcessor.java coyote/ajp/AjpProcessor.java jk/common/HandlerRequest.java
Author: billbarker
Date: Wed Jun 13 19:55:26 2007
New Revision: 547096
URL: http://svn.apache.org/viewvc?view=revrev=547096
Log:
Porting large-file support for the AJP Connectors from 5.5
Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diffrev=547096r1=547095r2=547096
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed Jun 13
19:55:26 2007
@@ -680,7 +680,9 @@
if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
} else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
@@ -1204,7 +1206,7 @@
if (endOfStream) {
return -1;
}
-if (first req.getContentLength() 0) {
+if (first req.getContentLengthLong() 0) {
// Handle special first-body-chunk
if (!receive()) {
return 0;
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?view=diffrev=547096r1=547095r2=547096
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Wed Jun 13
19:55:26 2007
@@ -688,7 +688,9 @@
if (hId == Constants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-request.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+request.setContentLength( (int)cl );
} else if (hId == Constants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
@@ -1144,7 +1146,7 @@
if (endOfStream) {
return -1;
}
-if (first req.getContentLength() 0) {
+if (first req.getContentLengthLong() 0) {
// Handle special first-body-chunk
if (!receive()) {
return 0;
Modified: tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java?view=diffrev=547096r1=547095r2=547096
==
--- tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java (original)
+++ tomcat/trunk/java/org/apache/jk/common/HandlerRequest.java Wed Jun 13
19:55:26 2007
@@ -407,7 +407,7 @@
// Check to see if there should be a body packet coming along
// immediately after
-int cl=req.getContentLength();
+long cl=req.getContentLengthLong();
if(cl 0) {
JkInputStream jkIS = ep.getInputStream();
jkIS.setIsReadRequired(true);
@@ -577,7 +577,9 @@
if (hId == AjpConstants.SC_REQ_CONTENT_LENGTH ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Length))) {
// just read the content-length header, so set it
-req.setContentLength( vMB.getInt() );
+long cl = vMB.getLong();
+if(cl Integer.MAX_VALUE)
+req.setContentLength( (int)cl );
} else if (hId == AjpConstants.SC_REQ_CONTENT_TYPE ||
(hId == -1 tmpMB.equalsIgnoreCase(Content-Type))) {
// just read the content-type header, so set it
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
