Re: Tomcat Comet Model, DOS example

Filip Hanik - Dev Lists wrote: I agree, chunked would be the way to go for a communication. I reverted my fix, however, now TC6 has a DOS possibility, by following these steps 1. Override CometServlet.read, always return true (you wanna serve N client requests, and you don't know how many it

Re: Tomcat Comet Model

Costin Manolache wrote: Not sure I understand all details here - but chunking seems like a better solution than sending a bad Content-Length. Indeed, you got it right, chunking is supposed to be used. Sending a too large or incorrect content-length may break a lot of things ( and be rejected,

svn commit: r414986 - /tomcat/container/branches/tc4.1.x/build.properties.default

Author: markt Date: Fri Jun 16 19:43:05 2006 New Revision: 414986 URL: http://svn.apache.org/viewvc?rev=414986&view=rev Log: Revert version number in head after tagging Modified: tomcat/container/branches/tc4.1.x/build.properties.default Modified: tomcat/container/branches/tc4.1.x/build.prop

svn commit: r414985 - /tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_32/

Author: markt Date: Fri Jun 16 19:41:25 2006 New Revision: 414985 URL: http://svn.apache.org/viewvc?rev=414985&view=rev Log: Tagging 4.1.32 Added: tomcat/servletapi/tags/servlet2.3-jsp1.2-tc4.x/TOMCAT_4_1_32/ - copied from r414984, tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/ -

svn commit: r414984 - /tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_32/

Author: markt Date: Fri Jun 16 19:39:30 2006 New Revision: 414984 URL: http://svn.apache.org/viewvc?rev=414984&view=rev Log: Tagging 4.1.32 Added: tomcat/jasper/tags/tc4.1.x/TOMCAT_4_1_32/ - copied from r414983, tomcat/jasper/branches/tc4.1.x/ -

svn commit: r414983 - /tomcat/container/tags/tc4.1.x/TOMCAT_4_1_32/

Author: markt Date: Fri Jun 16 19:38:53 2006 New Revision: 414983 URL: http://svn.apache.org/viewvc?rev=414983&view=rev Log: Tagging 4.1.32 Added: tomcat/container/tags/tc4.1.x/TOMCAT_4_1_32/ - copied from r414982, tomcat/container/branches/tc4.1.x/ ---

svn commit: r414982 - /tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_32/

Author: markt Date: Fri Jun 16 19:36:36 2006 New Revision: 414982 URL: http://svn.apache.org/viewvc?rev=414982&view=rev Log: Tagging 4.1.32 Added: tomcat/connectors/tags/tc4.1.x/TOMCAT_4_1_32/ - copied from r414980, tomcat/connectors/trunk/

svn commit: r414980 - /tomcat/container/branches/tc4.1.x/build.properties.default

Author: markt Date: Fri Jun 16 19:32:10 2006 New Revision: 414980 URL: http://svn.apache.org/viewvc?rev=414980&view=rev Log: Update version number prior to tagging Modified: tomcat/container/branches/tc4.1.x/build.properties.default Modified: tomcat/container/branches/tc4.1.x/build.propertie

Re: Tomcat Comet Model, DOS example

I agree, chunked would be the way to go for a communication. I reverted my fix, however, now TC6 has a DOS possibility, by following these steps 1. Override CometServlet.read, always return true (you wanna serve N client requests, and you don't know how many its gonna send, so this is not un

RE: using svn to checkout the code; compiling tomcat

I've upgraded my ant from 1.6.1 to 1.6.5. That fixed it. Thanks to all! -Derek On 6/16/06, Derek Lac <[EMAIL PROTECTED]> wrote: > My ant version is 1.6.1. My java version is 1.5.0. > > > > -Derek > > > C:\dev\svn\tc5.5.x\build>java -version > java version "1.5.0_06" > Java(TM) 2 Runtime Environm

Re: Tomcat Comet Model

Not sure I understand all details here - but chunking seems like a better solution than sending a bad Content-Length. Sending a too large or incorrect content-length may break a lot of things ( and be rejected, affect proxies, etc ). Costin On 6/16/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED

Re: Tomcat Comet Model

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: yes, but to do so, you would be required to pre calculate the content length for the 2 (or N events), and if the server hasn't responded (since its async) you can't send the 2nd event as you could start a new HTTP request on the same connect

svn commit: r414965 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Author: fhanik Date: Fri Jun 16 17:12:20 2006 New Revision: 414965 URL: http://svn.apache.org/viewvc?rev=414965&view=rev Log: Revert, if Content-Length: is an acceptable work around Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java tomcat/tc6.0.x/trun

Re: Tomcat Comet Model

Lemme narrow everything down, and this will be short, I promise, it all boils down to the Content-Length header, if this header is omitted then it wont be possible for the client to send more than one request. The workaround for this, Content-Length: Integer.MAX_VALUE, this will make the code

Re: Tomcat Comet Model

Filip Hanik - Dev Lists wrote: yes, but to do so, you would be required to pre calculate the content length for the 2 (or N events), and if the server hasn't responded (since its async) you can't send the 2nd event as you could start a new HTTP request on the same connection when there hasn't b

Re: Tomcat Comet Model

Filip Hanik - Dev Lists wrote: and that is the exact bug I fixed. Before the commit, you couldn't. So to support your argument, you should be in favor of the commit. not against. Ok, then post the request you are sending. The whole request must be a valid HTTP/1.1 request with a properly deli

Re: Tomcat Comet Model

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: all, I have made a little image that would explain the idea I have (and implemented today) for the Tomcat model, would like to get some feedback, Remy and I already have an open dialogue, but its subjected under a commit, so if you didn't

DO NOT REPLY [Bug 39821] - JK busy number is abnormal

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Comet, next steps

Filip Hanik - Dev Lists wrote: Unfortunately, it looks like it: +for (int i=0; i+//this resets the remaining flag and the content length on the filter +//if we don't do this, then request.getInputStream.read will return 0 +

Re: Tomcat Comet Model

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: all, I have made a little image that would explain the idea I have (and implemented today) for the Tomcat model, would like to get some feedback, Remy and I already have an open dialogue, but its subjected under a commit, so if you didn't

Re: Tomcat Comet Model

Filip Hanik - Dev Lists wrote: all, I have made a little image that would explain the idea I have (and implemented today) for the Tomcat model, would like to get some feedback, Remy and I already have an open dialogue, but its subjected under a commit, so if you didn't read that one, this one

Re: Comet, next steps

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Actually, I think the server should be the one closing the connection. In other cases, since it's a long running request, discarding the connection is easier. In HTTP land, the server is always the one in control of keepalive. That's correct

Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Filip Hanik - Dev Lists wrote: I hear you loud and clear, I've addressed the bug in my previous email. In terms of breaking HTTP, the comet model already does this, as it would block the client from sending data until the server decides it is done sending data to the client, which it can do mor

Tomcat Comet Model

all, I have made a little image that would explain the idea I have (and implemented today) for the Tomcat model, would like to get some feedback, Remy and I already have an open dialogue, but its subjected under a commit, so if you didn't read that one, this one has a nice pix also available a

Re: Comet, next steps

Filip Hanik - Dev Lists wrote: Actually, I think the server should be the one closing the connection. In other cases, since it's a long running request, discarding the connection is easier. In HTTP land, the server is always the one in control of keepalive. That's correct, however, the current

Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: what part, the check in or the feature set? The commit. the check in, fixes data transfer by doing comet style, ie, both client and server can "push" data, and working around the HTTP request/response pull model. most containers only impl

Re: Comet, next steps

Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Gents, I have played around with the Comet implementation, fixed a few bugs and got the initial it working, including async data from both client and server. I wanted to you get your input on moving forward with the follow

Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Filip Hanik - Dev Lists wrote: what part, the check in or the feature set? The commit. the check in, fixes data transfer by doing comet style, ie, both client and server can "push" data, and working around the HTTP request/response pull model. most containers only implement "server async pus

Re: Comet, next steps

Filip Hanik - Dev Lists wrote: Gents, I have played around with the Comet implementation, fixed a few bugs and got the initial it working, including async data from both client and server. I wanted to you get your input on moving forward with the following features: 1. If CometServlet.read

Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Fri Jun 16 13:55:06 2006 New Revision: 414906 URL: http://svn.apache.org/viewvc?rev=414906&view=rev Log: Fixed comet processing. The following bug was existing: When a comet request had begun, and the browser sent some more dat

Re: using svn to checkout the code; compiling tomcat

Hi, Then I just can't reproduce what you're seeing. Clean builds from scratch work for me all the time, using JDK 1.5 and 1.4, Ant version 1.6.5, both Windows XP and FreeBSD. Yoav On 6/16/06, Derek Lac <[EMAIL PROTECTED]> wrote: My ant version is 1.6.1. My java version is 1.5.0. -Derek C:

Re: using svn to checkout the code; compiling tomcat

use the latest version of ant, then run this script, and you probably forgot to run "ant download" first #!/bin/sh # # This is a quickie helper script to  easily build tomcat 5 from source. # This will create a subdire

Re: svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

[EMAIL PROTECTED] wrote: Author: fhanik Date: Fri Jun 16 13:55:06 2006 New Revision: 414906 URL: http://svn.apache.org/viewvc?rev=414906&view=rev Log: Fixed comet processing. The following bug was existing: When a comet request had begun, and the browser sent some more data, the Tomcat APR comp

RE: using svn to checkout the code; compiling tomcat

My ant version is 1.6.1. My java version is 1.5.0. -Derek C:\dev\svn\tc5.5.x\build>java -version java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) C:\dev\svn\tc5.5.x\build>ant -ver

Re: using svn to checkout the code; compiling tomcat

Hola, What Ant version are you using? Tomcat requires Ant v1.5 or later. Yoav On 6/16/06, Derek Lac <[EMAIL PROTECTED]> wrote: After using svn to get tc5.5.x, using 'ant download', and running 'ant', I get the following compile error. This is the same compile error I get when I attempt to dow

RE: using svn to checkout the code; compiling tomcat

After using svn to get tc5.5.x, using 'ant download', and running 'ant', I get the following compile error. This is the same compile error I get when I attempt to download the beta sources and compiling directly. -Derek [mkdir] Created dir: C:\dev\svn\tc5.5.x\build\build\server\classes bui

RE: rfc2109 and TC cookies

> -Original Message- > From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] > Sent: Friday, June 16, 2006 2:50 PM > To: Tomcat Developers List > Subject: Re: rfc2109 and TC cookies > > Jean-frederic Clere wrote: > > Hi, > > > > I have been reading rfc2109 it gives an examples of coo

Re: using svn to checkout the code; compiling tomcat

Hi, Slight scramble of your message: Obviously, I need to get check the jsp code to build as well. Checking on the web, I realize I also need the following modules: * /build/tc5.5.x * /container/tc5.5.x * /connectors/trunk * /jasper/tc5.5.x * /servletapi/servlet2.4-jsp2.0-t

Comet, next steps

Gents, I have played around with the Comet implementation, fixed a few bugs and got the initial it working, including async data from both client and server. I wanted to you get your input on moving forward with the following features: 1. If CometServlet.read return false, the adapter should

Re: rfc2109 and TC cookies

Jean-frederic Clere wrote: Hi, I have been reading rfc2109 it gives an examples of cooky like (as the spec's states): +++ Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme" +++ not sure where that syntax comes from, from what I read it looks 4.2.2 Set-Cookie Syntax Th

Fwd: [VOTE] Time for 4.1.32?

FWIW (mail trouble) -- Forwarded message -- From: Keith Wannamaker <[EMAIL PROTECTED]> Date: Jun 11, 2006 9:28 AM Subject: Re: [VOTE] Time for 4.1.32? To: Tomcat Developers List On 6/10/06, Mark Thomas <[EMAIL PROTECTED]> wrote: [X] +1 I am in favour of a 4.1.32-beta release

rfc2109 and TC cookies

Hi, I have been reading rfc2109 it gives an examples of cooky like (as the spec's states): +++ Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme" +++ But TC sends: +++ [EMAIL PROTECTED]:~/apache-tomcat-5.5.15$ telnet localhost 8080 Trying 127.0.0.1... Connected to localhos

RE: using svn to checkout the code; compiling tomcat

Sorry for being a newcomer and spaming the list with newbie question, but... I've used svn co http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x tomcat. Edit the build.properties to point to c:\dev\svn When I compile tomcat/build by running 'ant', I get the following error: BUILD FAILED C:\

Re: using svn to checkout the code; compiling tomcat

Hi, I haven't tried to build 4.x or 5.0 in a while, but 5.5 works fine. I just did a clean build from scratch, no problems. Here's how: svn co http://svn.apache.org/repos/asf/tomcat/current/tc5.5.x tomcat cd tomcat/build // customize your build.properties if/as needed ant download ant Yoav On

svn commit: r414906 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Http11AprProcessor.java InternalAprInputBuffer.java

Author: fhanik Date: Fri Jun 16 13:55:06 2006 New Revision: 414906 URL: http://svn.apache.org/viewvc?rev=414906&view=rev Log: Fixed comet processing. The following bug was existing: When a comet request had begun, and the browser sent some more data, the Tomcat APR component was never reading the

using svn to checkout the code; compiling tomcat

Hi, I've downloaded various versions of the 5.5 sources, and they all failed with different reason. When I use svn to checkout the code, I get the following error: svn: Can't check path 'tomcat\watchdog\branches\other\tc3.x\Apache_Jakarta\src\c lients\org\apache\jcheck\jsp\client\.:': The

DO NOT REPLY [Bug 39826] - HttpSession object is being recreated

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39826] - HttpSession object is being recreated

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39826] New: - HttpSession object is being recreated

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39824] New: - Tomcat 5.5.16+ memory realm on context not work

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38389] - java.util.Arrays.Sort() crashes with AbstractMethodError when compiled using JDT, but works OK when compiled with ant

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [mod_jk] Documentation

[EMAIL PROTECTED] wrote: Quoting Jean-frederic Clere <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: Quoting David Rees <[EMAIL PROTECTED]>: On 6/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: My problem is not a user problem, for the moment I don't want to us

Re: [mod_jk] Documentation

Quoting Jean-frederic Clere <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > >>Quoting David Rees <[EMAIL PROTECTED]>: > >> > >> > > > > > > > >>>On 6/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >>>My problem is not a user problem, for the moment I don't want to use > >>>mod_jk, I > >

DO NOT REPLY [Bug 39813] - JMX proxy servlet newline escaping is incorrect

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [mod_jk] Documentation

[EMAIL PROTECTED] wrote: Quoting David Rees <[EMAIL PROTECTED]>: On 6/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: My problem is not a user problem, for the moment I don't want to use mod_jk, I only want to modify it and thus understand the mod_jk code before. So I think my que

Re: [mod_jk] Documentation

> Quoting David Rees <[EMAIL PROTECTED]>: > > On 6/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > My problem is not a user problem, for the moment I don't want to use > > mod_jk, I > > only want to modify it and thus understand the mod_jk code before. So I > > think > > my question might

DO NOT REPLY [Bug 39704] - context with privileged="true" do not setup properly inner loaders

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu